Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

A RESTful service is currently protected against XSS attacks by applying XML schema- and entity validation. In both cases this is done via a regular expression like:

<xs:pattern value="[0-9]{1}[0-9a-z/\\ -]{0,7}" />

Can this validation be considered as a reliable countermeasure against XSS, or do I need to implemend further security measures?

share|improve this question

2 Answers 2

up vote 1 down vote accepted

There are a few angles here:

(1) Misinterpretation of correctly-generated non-HTML response type as dangerous HTML. This is what Rook's answer is talking about, on the assumption that your REST service is returning a response such as JSON or XML. Problem here is that some browsers (in particular IE) could ignore the stated Content-Type and treat a document as being HTML because it has some magic string like <html in the first /n/ bytes.

A defence against this in modern browsers is to use the header X-Content-Type-Options: nosniff, which is a good thing to do in all responses generally. To cover all cases you can use encoding rules for your format to avoid putting potentially-sensitive variable text in an encoding form that can't be misinterpreted as HTML. Typically this means writing < as \u003C in JSON strings, even though < is not normally a character that needs escaping in JSON. With XML you are covered for that as you need to encode a literal < to &lt; anyway. Other characters there are arguments for encoding (though the attacks are extremely marginal) are + and {.

(2) Incorrectly-generated response, missing correct encoding for format.

Input validation is a good defence-in-depth measure as well as a good way to enforce business rules. But it does not blanket-protect you from injection vulnerabilities. If you put together an XML or JSON response by adding strings together without explicit escaping, you've got the potential for an attacker to cause malformed responses that may get interpreted by another caller. This probably wouldn't result in direct XSS, but it could certainly cause app-specific logical problems.

Use the correct form of string encoding for your context every time you add strings together, or, better, use data output libraries that do it automatically (eg standard JSON or XML serialiser). This makes sure your response is correct, and the security is a side-effect of that correctness.

(3) XML document types. This is a mixture of (1) and (2), where injection gives you the possibility of interpreting XML as a different kind of XML. If you've got an XML-injection problem, an attacker might be able to include an element in your response with an xmlns pointing to the XHTML or SVG namespaces. If the document is loaded directly into a web browser, these can include script content that executes in that site's origin, and there you again potentially have XSS.

(4) DOM XSS—bad client-side handling of response. If the REST response is being consumed by a web browser script that takes a value in the response and sets innerHTML to that, you've still got an HTML-injection vulnerability, just in a slightly different place.

share|improve this answer
    
Thank you, great answer! I just have some understanding problems. Can you please explain the two sentences a bit more. With XML you are covered for that as you need to encode a literal < to &lt; anyway. Other characters there are arguments for encoding are + and { Do I need to consider this if I use JAXB to create the response body? According to point 3, I have disabled to resolve external entities for the XML parser. I this sufficient? Thanks a bunch. –  My-Name-Is Sep 10 '13 at 9:42
1  
JAXB will use a standard XML serialiser to produce output so you should be safe from straight XML-injection issues, which will protect you from issues in (3) too. It won't escape +/{ but the attacks there are pretty unlikely (as modern browsers don't use UTF-7 or E4X) so I wouldn't necessarily lose sleep over it. Disabling external entities (and indeed doctype-internal-subset-defined-entities) is a good thing, though not related to XSS as such. –  bobince Sep 10 '13 at 10:22
    
Thank you! One last question. Since CSRF is a serious issue, I want ask you for your opinion to this http://security.stackexchange.com/questions/42093/xss-prevention-for-restful-se‌​rvices issue too. Please add your experience to this. Thanks a bunch. –  My-Name-Is Sep 10 '13 at 14:24

The content-type used by web services should indicate to the browser not to interpreter the response as executable JavaScript code. For example, a RESTful web service can use application/json or application/xml depending on the marshaling type used. It is impossible for an attacker to obtain XSS with these content-types, regardless of the contents of the body.

Something to watch out for is accidentally setting the content-type to text/html or omitting it entirely as this could lead to XSS in a web service.

share|improve this answer
    
Thank you for that answer. That sounds reasonable. For testing purposes I created a XML file that contains valid html (login form that submits the entered credentials to another web site) If I opened this local file via file:///C:/xss.xml the html was rendered as expected as html site. As I tried to request the same content from the REST service the content was alway displayed as text. I experimented it with different browsers and content types like text/xml, application/xml and even with text/html. In none of these cases a XSS attack was possible. So thank you for your conformation. –  My-Name-Is Sep 9 '13 at 19:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.