1

Is this apart of a HTTP Response Splitting attack ? Here below is some code that gets put into a web browser after clearing the url while on the website

javascript: var xhr = new XMLHttpRequest(); xhr.open( "GET" , "google.com", false);
xhr.send(); document.write(xhr.getAllResponseHeaders());

and the out put of this code will look like something like this

Date: Fri, 18 Jan 2013 10:40:10 GMT Content-Encoding: gzip Transfer-Encoding: chunked 
Connection: close Server: Apache/2.2.3 (Red Hat) Vary: Cookie,Accept-Language,
Accept-EncodingContent-Language: en-us Content-Type: text/html; charset=utf-8

If using more AJAX and JavaScript and setting header

setRequestHeader(header,value)

is this a security risk for all browsers on every web application ?

Improve this question

2 Answers 2

Reset to default
2

HTTP response splitting attacks work when user data (including newlines) can be injected into HTTP headers.

For example, let's take this response:

 HTTP/1.1 200 OK
 Date: Mon, 23 May 2005 22:38:34 GMT
 Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
 Last-Modified: Wed, 09 Jan 2013 23:11:55 GMT
 Accept-Ranges:  none
 Content-Length: 1234
 Connection: close
 Content-Type: text/html; charset=UTF-8
 Cookie: test=123&username=Polynomial

 <html>
 ...

Now let's assume I can change my username arbitrarily, and include CRLF (newlines) in the field. I could then inject my own content into the page.

For example, I might set my username to Polynomial\r\n\r\n<script>alert(document.cookie)</script>, which would result in the following HTTP response:

 HTTP/1.1 200 OK
 Date: Mon, 23 May 2005 22:38:34 GMT
 Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
 Last-Modified: Wed, 09 Jan 2013 23:11:55 GMT
 Accept-Ranges:  none
 Content-Length: 1234
 Connection: close
 Content-Type: text/html; charset=UTF-8
 Cookie: test=123&username=Polynomial

 <script>alert(document.cookie)</script>
 <html>
 ...

As you can see, the JavaScript was injected into the page. This is a form of XSS / DOM injection via the splitting attack.

Including user data in a request isn't quite as bad, since the server should treat user requests as untrusted anyway. As such, AJAX requests shouldn't be an issue. This becomes even less of a problem when you consider the fact that most major browsers have disabled or limited the javascript: handler in the URL bar, in order to limit the potential for attacks.

Improve this answer
4
  • So this wouldn't be considered a very serious attack ?
    – noob1992
    Jan 18, 2013 at 12:47
  • It would be considered very serious if you were able to attack the response, but if you can only attack the request it's much more of an "it depends", in that it requires a second vulnerability in order to exploit anything properly. Either way, you should fix splitting bugs if you find them.
    – Polynomial
    Jan 18, 2013 at 13:31
  • +1, although if someone tried to follow these steps it wouldn't work because the content length is incorrect and the browser will error out! You are leaving out a required step of the exploitation process.
    – rook
    Jan 18, 2013 at 21:21
  • True - you'd have to send a second content length header.
    – Polynomial
    Jan 19, 2013 at 12:38
0

Manually writing JavaScript in the browser location bar using the javascript: protocol handler will execute that JavaScript in the context of the website loaded in the current tab.

There is no feature that will allow an attacker to automatically put that JavaScript in the location bar and run it. There have been worms that ask the user to copy malicious JavaScript and paste it in the address bar.

Improve this answer
5
  • Wait what ? What do you mean ?@CristianDobre
    – noob1992
    Jan 18, 2013 at 11:34
  • From your question, I understand that you write "javascript: var xhr = new XMLHttpRequest(); xhr.op[...]" in the browser URL bar. Is this correct?
    – Cristian Dobre
    Jan 18, 2013 at 11:41
  • Yes that is correct
    – noob1992
    Jan 18, 2013 at 11:43
  • This is a feature of the browser. You can run JavaScript this way. It is not a way of exploiting your browser or a web application. If an attacker could automatically run JS in YOUR browser this way, that could be a security problem. But that is not possible as far as I know. There is the possibility of social engineering nathanhammond.com/social-engineering-issue-with-javascript-urls. Chrome protects against this by not allowing you to paste (ctrl+v) the text "javascript:" in the URL bar.
    – Cristian Dobre
    Jan 18, 2013 at 11:56
  • 1
    Firefox fixes it by disabling the javascript: handler entirely for the address bar. Anyway, this doesn't answer the question.
    – Polynomial
    Jan 18, 2013 at 12:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .