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.

By default ASP.NET checks for HTTP Response Splitting attack when you do Response.Redirect:

Response.Redirect("/MySite/Default.aspx?lang=foobar%0d%0aContentLength:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContentType:%20text/html%0d%0aContentLength:%2019%0d%0a%0d%0a<html>Shazam</html>");

Result - error page:

A potentially dangerous Request.QueryString value was detected from the client (lang="...th: 19

<html>Shazam</html>").

Description: Request Validation has detected a potentially dangerous client input value, and processing of the request has been aborted. This value may indicate an attempt to compromise the security of your application, such as a cross-site scripting attack. You can disable request validation by setting validateRequest=false in the Page directive or in the configuration section. However, it is strongly recommended that your application explicitly check all inputs in this case. 

Is there any other way to perform HTTP Response Splitting attack on default ASP.NET website configuration? What about ASP.NET MVC?

share|improve this question
    
Can you just provide one element: %0acookie: test=1 –  Rook Jan 16 '12 at 18:57
2  
I would be very surprised if HTTP Response Splitting were possible. This is an attack that is trivially solved by the framework, it usually affects applications not using any framework or using one that is immature. HttpResponse.AppendHeader simply has to disallow newlines in header names and values, this is sufficient to prevent the attack. And I mostly certain that it does that and what you've hit here is actually the second line of defense. –  Wladimir Palant Jan 19 '12 at 14:30
add comment

1 Answer

up vote 5 down vote accepted

This is going to be an annoyingly trivial answer, BUT...

The only way to perform a Response Splitting attack on an updated ASP.NET (or MVC) server, is if the application itself is writing back raw HTTP responses.
Yes, of course no programmer in their right mind would do that... but in the case of the 60% of programmers that are not in their right mind, it is possible likely that such an implementation would be vulnerable.

Otherwise, no, the application is not vulnerable to HRS.

share|improve this answer
add comment

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.