I just pulled out a piece of code which I wrote a few months ago. The code fetches an XML document from a web server and parses it using JAXB. The last time I tried it worked flawlessly; now I am getting an exception:
org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId.
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257)
at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:339)
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121)
Looking around, this suggests some issues with the XML header data, namely <!DOCTYPE ...>. The answer suggests that the statement is misleading: in the case described, systemId was missing altogether, despite the error just complaining about a missing whitespace in front of it.
However, if I get the XML document with a web browser, it doesn’t even contain the <!DOCTYPE ...> header.
Parsing an XML document I retrieved a few months back works without issues.
If I diff the document I retrieved today and the one from a few months back, both are exactly the same up to the start of the root element.
Capturing the HTTP traffic finally provided the answer (unencrypted connections come in handy at times): Apparently the service switched from HTTP to HTTPS in the last few months, with URLs remaining unchanged otherwise.
Requests to the old URL are answered with 301 Moved Permanently and the new URL.
When reading from a URL with java.net.URL.openStream(), redirects are not followed automatically. Thus, the data it returns is not valid XML, leading to the error message.
Lesson learned for today: White spaces are required between publicId and systemId is really just a cryptic way of saying: Something’s wrong with the XML data you supplied, but we didn’t bother to dig any deeper.
Related
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 have to call xml parsing I am receiving this error "NSXMLParserErrorDomain error 64", if I will parse dynamically I will get this error. statically parsing on that same xml I get my attribute values.
If i will try another one server different request,url and response it will working properly the xml parsing and i am getting attribute values.
Please check this link==>http://brandontreb.com/wordpress-for-iphoneipad-nsxmlparsererrordomain-error-64-resolved
*After scouring the internet, I found that this could be the result of a few issues.
1) Special characters in a post body that are not supported by NSXMLParser
2) Special characters in a comment
3) Invalid post or comment RSS
4) An error in a theme/plugin file
For me, this turned out to be an issue with the comments RSS feed. I loaded it up in the browser and long behold, even the browser threw an error. But what could be causing this? Turns out, I had left a space in a plugin that I created. This caused a space to be output at the beginning of the comments XML, causing it to error. Notice the space between ?> and
After removing the space from this plugin, I loaded up WordPress for iPhone and it added my blog without a problem.
So, the take away from this is don’t output spaces when you create a plugin.*
Hope this helps you...:-)
In my case, it was only the blank line at the beginning of the file that was causing the issue. Error code 64 is for misplaced XML declaration as you can see in the documentation:
NSXMLParserMisplacedXMLDeclarationError = 64,
Misplaced XML declaration.
I have a problem with values POSTed via h:commandbutton, when I enter special characters (ö, ä. ñ, ..). When the value is submitted via an ajax request (e.g. a change listener on the value, or a4j:commandbutton) everything works find. However when the value is submitted via h:commandbutton, the value received gets garbled.
I've tried to set everything according to the article written by BalusC.
I've set the URI enconding in JBoss' standalone.xml:
<property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
<property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>
Added a filter that sets the character encoding of the request. However this does not change anything, the parameters are messed up there if I read get the param map (either before or after setting the encoding).
Is there anything else I've missed?
I've tried with JBoss 7.1.0 and 7.1.1 and richfaces 4.1.0.
Edit:
Even if ExternalContext#getRequestCharacterEncoding() returns UTF-8 in the beans action method (as asked in the comment), it looks like the filter is the problem.
When the form is submitted via h:commandButton, request.getCharacterEncoding() returns null at the beginning of the doFilter() method of the UTF filter I added. But request.parametersParsed is already true.
When the value is submitted via ajax request.getCharacterEncoding() is already UTF-8.
So it looks like the encoding is set differently and some other filter already parses the parameters. The only other filter in the request.context.filterConfigs is org.jboss.weld.servlet.ConversationPropagationFilter. Plus Picketlink probably already has read the parameters at this point.
Edit 2:
As discussed in this thread in the PL forum this seems to be a bug in Picketlink. Also check the related PL issue.
Everything looks fine so far.
This construct will only fail if something else has already accessed (and thus implicitly parsed) the request body before your character encoding filter has set the request body character encoding. It's then too late to set the character encoding for parsing of the request body.
Based on the comments, PicketLink seems to be the culprit here. You need to tell it to use UTF-8, or if that's not possible, report a bug/issue report at their development team. This all is at least beyond control of JSF and hence not a JSF related problem.
ASP.Net MVC 3.0, .NET 4.0, IIS 7
I know it has been asked a many times, but I still can't figure out what's wrong with it.
I get these messages only occasionally (less than 1 a day), and I get about 4k visits daily.
Here is a link to the error report:
http://wowreforge.com/elmah.axd/detail?id=6CBE6DCA-88C2-45E7-AF53-A53061B8E25D
(notice there are links to XML and JSON detailed reports)
First thing to note is URL (PATH) contains UTF-8 encoded character : /US/Warsong/Spartan%C3%B6
second thing, request is HEAD, not GET
Neither one of those details should result in the error I receive, I think.
The original URL was:
http://wowreforge.com/US/Warsong/Spartan%C3%B6?reforge=--52145254126214646464--3214325254&crit=7&dodge=90&exp=19&haste=1&hit=10&mastery=100&parry=67&spi=0
I have tried this URL with both GET and HEAD request, but wasn't able to reproduce the error.
Anything else I can poke at?
Notice that PATH_TRANSLATED = E:\web\wowreforgec\htdocs\EU\Kael%27Thas\Acekhor. It looks like the URL encoded character %27 is not being translated to ' before looking up the path of the file on disk. The % character is forbidden by the default configuration of the RequestPathInvalidCharacters property, thus the input is considered dangerous and an exception is thrown.
Edit
The HttpUtility.UrlDecode(string s) method should transform /EU/Kael%27Thas/Acekhor into /EU/Kael'Thas/Acekhor. This method (or one of similar function) should be called at the point where the virtual path is resolved to a physical path. Are you using a custom method to transform the virtual path into a physical path?
Currently, when I try to hit certain pages of my site via something like http://www.domain.com/< (which is a valid URL), I get a blank page with the text "Bad Request" on it (and nothing else). This happens with both the escaped and unescaped version of the URL.
I'm fairly certain this is due to IIS6 not liking the < character (which, in general, is valid). Is there a way to stop IIS6 from filtering these characters and giving me this error page?
(I've found similar solutions for IIS7, but nothing has worked in IIS6 so far.)
UPDATE: The URL is being transformed already, ie. hitting domain.com/%3C will also give the "Bad Request" page.
Not sure if this will work, but this got me out of a similar jam caused by design types forgetting key parts of query strings. Sounds like you might have a similar issue. Anyhow, try making a virtual directory called %3c and then having that redirect to where appropriate.
RFC 1738:
Thus, only alphanumerics, the special characters "$-_.+!*'(),", and reserved characters used for their reserved purposes may be used unencoded within a URL.
< transforms to %3C
https://stackoverflow.com/<