I have an application that creates messages in Microsoft M365 using the Graph API. I use the "body" element with sub-properties "contentType" and "content" to specify the text of the message. When contentType is HTML, the HTML that goes into content is not made by my application, rather it is transferred from an external source, and I don't attempt to modify it in any way. The problem I'm having with one specific message is that it is encoded in ISO-8859-1 instead of UTF8, and M365 will not display the non-English characters correctly. The HTML itself has a META tag that specifies the character set:
META HTTP-EQUIV=\"Content-Type\" CONTENT=\"text/html; charset=iso-8859-1\">
And in fact this HTML body looks fine when displayed by itself in a browser window, it's just M365 that screws up the rendering. Is there I way I can tell Graph or M365 what the character set is for this property?
Related
Inline with this thread
How do we get the document file url using the Watson Discovery Service?,
I tried adding url field inside HTML document under various tags like p, directly as
<"url">...<"/url"> etc inside <"body"> tag.
Whatever I do, this url field that I am trying to add is not getting reflected either under extracted_metadata or under html or under text in the json when I see the resulting json after conversion / enrichment in the discovery tooling. Can someone throw some hint on what I can do to get url field just like title under extracted_metadata section in the json output?
I have a Rails/Ember one-page app. Burp reports that
The value of the 'content_type' JSON parameter is copied into the HTML
document as plain text between tags. The payload
da80balert(1)4f31e was submitted in the content_type
JSON parameter. This input was echoed unmodified in the application's
response.
I can't quite parse this message referring to "is copied into" and "was submitted" in, but basically what is happening is:
A PUT or POST from the client contains ...<script>...</script>... in some field.
The server handles this request, and sends back the created object in JSON format, which includes the string in question
The client then displays that string, using the standard Embers/Handlebars {{content_type}}, which HTML-escapes the string and inserts it into the DOM, so the browser displays it on the screen as originally entered (and of course does NOT execute it).
So yes, the input was indeed echoed unmodified in the application's response. However, the application's response was not HTML, in which case there would indeed be a problem, but JSON, containing strings which when referred to by Handlebars will always be escaped properly for proper display in the browser.
So my question is, is this in fact a vulnerability? I have taken great care with my Ember app and can prove that no data from JSON objects is ever inserted "raw" into the DOM. Or is this a false positive given rise to by the mere fact the unescaped string may be found in the response if looked for using an unintelligent string comparison, not taking into account the fact that the JSON will be processed/escaped by the client-side framework?
To put it a different way, in a classic webapp spitting out HTML from the server, we know that user input such as the above must be escaped/sanitized properly. Unsanitized data "on the wire" in and of itself represents a vulnerability. However, in a one-page app based on JSON coming back from the server, the escaping/sanitization occurs in the client; the JSON on the "wire" may contain unsanitized data, and this is as expected. Am I missing something here?
There are subtle ways in which you can trick IE9 and older into treating JSON as HTML. So even if the server's response has a Content-Type header of application/json, IE will second guess it. This is called content type sniffing, and can be disabled by adding the X-Content-Type-Options: nosniff header.
JSON is not an executable format so your understanding is correct.
I did a demo of this exact problem in my talk on securing single page web apps at OWASP AppSec EU 2013 which someone put up on youtube here: http://m.youtube.com/watch?v=Femsrx0m9bU
I run a small e mail client build with delphi and indy 10. Some mails i receive have the mime format or html format. With the current code I just copy the bode.lines to a memo.lines
MyMailMemo.Lines.AddStrings
(TIdMessage(Msg.Body);
How do I copy the content of mime emails?
MIME-encoded emails do not use the TIdMessage.Body property. They use the TIdMessage.MessageParts property instead, where textual MIME parts are stored as TIdText objects and attachments are stored as TIdAttachment-derived objects. You have to look at the TIdMessage.ContentType property to know whether you are working with an HTML email or a MIME email. Even then, chances are that HTML emails are actually MIME encoded, as they usually include an alternative plain-text MIME part for non-HTML email readers. You can loop through the TIdMessage.MessageParts looking for a TIdText object whose ContentType is HTML, then copy the TIdText.Body content into your TMemo.
I have a basic form that asks the user to enter some text in a regular html input control and I am also using jquery-tokeninput to allow users to choose tags from a pre-filled list.
One of the tags in the pre-filled list happens to be the word café, which I have got from the server and populating the tag list by calling
mytaglist.push({id: 'café', name: 'café'});
The problem is that when they attempt to enter a word like 'café' as a tag, asp.net mvc rejects the input saying that:
A potentially dangerous Request.Form value was detected from the client (articleTags="café").
Inspection using firebug shows my post data to be something like:
UserName=neo&category=&Title=caf%C3%A9&Text=sometext&articleTags=caf%26%23233%3B&IsAgreedTerms=true
As you can see, Title has value caf%C3%A9 which is correct but articleTags has value caf%26%23233%3B which I was not expecting.
I absolutely need to make sure that café (and not some encoded value) appears on the screen.
How can I make sure that I send the correct post data and still display café everytime?
Should I change how my server sends the text?
sending the data via Html.Raw solves the problem..
I have in my browser.xul code,what I am tyring to is to fetch data from an html file and to insert it into my div element.
I am trying to use div.innerHTML but I am getting an exception:
Component returned failure code: 0x804e03f7
[nsIDOMNSHTMLElement.innerHTML]
I tried to parse the HTML using Components.interfaces.nsIScriptableUnescapeHTML and to append the parsed html into my div but my problem is that style(attribute and tag) and script isn`t parsed.
First a warning: if your HTML data comes from the web then you are trying to build a security hole into your extension. HTML code from the web should never be trusted (even when coming from your own web server and via HTTPS) and you should really use nsIScriptableUnescapeHTML. Styles should be part of your extension, using styles from the web isn't safe. For more information: https://developer.mozilla.org/En/Displaying_web_content_in_an_extension_without_security_issues
As to your problem, this error code is NS_ERROR_HTMLPARSER_STOPPARSING which seems to mean a parsing error. I guess that you are trying to feed it regular HTML code rather than XHTML (which would be XML-compliant). Either way, a better way to parse XHTML code would be DOMParser, this gives you a document that you can then insert into the right place.
If the point is really to parse HTML code (not XHTML) then you have two options. One is using an <iframe> element and displaying your data there. You can generate a data: URL from your HTML data:
frame.src = "data:text/html;charset=utf-8," + encodeURIComponent(htmlData);
If you don't want to display the data in a frame you will still need a frame (can be hidden) that has an HTML document loaded (can be about:blank). You then use Range.createContextualFragment() to parse your HTML string:
var range = frame.contentDocument.createRange();
range.selectNode(frame.contentDocument.documentElement);
var fragment = range.createContextualFragment(htmlData);
XML documents don't have innerHTML, and nsIScriptableUnescapeHTML is one way to get the html parsed but it's designed for uses where the HTML might not be safe; as you've found out it throws away the script nodes (and a few other things).
There are a couple of alternatives, however. You can use the responseXML property, although this may be suboptimal unless you're receiving XHTML content.
You could also use an iframe. It may seem old-fashioned, but an iframe's job is to take a url (the src property) and render the content it receives, which necessarily means parsing it and building a DOM. In general, when an extension running as chrome does this, it will have to take care not to give the remote content the same chrome privilages. Luckily that's easily managed; just put type="content" on the iframe. However, since you're looking to import the DOM into your XUL document wholesale, you must have already ensured that this remote content will always be safe. You're evidently using an HTTPS connection, and you've taken extra care to verify the identity of the server by making sure it sends the right certificate. You've also verified that the server hasn't been hacked and isn't delivering malicious content.