Hello participants of Mailing List. I hope you have found useful my previous classifications of XSS, SQL Injection and DoS vulnerabilities. Here is new one. In my article Classification of HTTP Response Splitting vulnerabilities (http://websecurity.com.ua/5007/), which I published few days ago, I told about different types of HTTP Response Splitting vulnerabilities. HTTP Response Splitting - it's vulnerabilities which belong to category of client-side attacks and they are widespread in modern web applications. And can be used for different attacks on users and visitors of web sites, including for conducting of XSS attacks. In classification WASC TC v2.0 HTTP Response Splitting have identifier WASC-25. ------------------------------------------------ Types of HTTP Response Splitting. ------------------------------------------------ There are next types of HTTP Response Splitting (HTTPRS): 1. Reflected HTTP Response Splitting. 2. Persistent HTTP Response Splitting. -------------------------------------------------- Reflected HTTP Response Splitting. -------------------------------------------------- Reflected HTTP Response Splitting - it's the most widespread type of HTTPRS vulnerabilities. At sending of special request to vulnerable web application, it responds at this request and at that another server header (or headers) is adding to its response. It allows to set arbitrary cookie to user of the site, to conduct XSS attack, to redirect to another site or to conduct other attack. Which occurs via adding of corresponding server headers. HTTPRS: http://site/page?p=%0AHeader:value HTTPRS + XSS: http://site/page?p=%0AContent-Type:html%0A%0A%3Cscript%3Ealert(document.cookie)%3C/script%3E --------------------------------------------------- Persistent HTTP Response Splitting. --------------------------------------------------- Persistent HTTP Response Splitting - it's another type of HTTPRS vulnerabilities, which I found in 2008 in FeedBurner FeedSmith plugin for WordPress (http://websecurity.com.ua/2384/). These vulnerabilities are more rare then Reflected HTTPRS, but at that they are more dangerous. At Persistent HTTPRS vulnerability the attack has permanent nature. After sending of special request to vulnerable web application, the data is saving at the server (in the file or DB) and are showing at requesting to corresponding scripts. It can be the same script which received request, or it can be other scripts (as in case of FeedBurner FeedSmith), after request to which occurs the adding of new server headers to response of web application. And at all further requests to this page (script) the attack will be occurring. Which allows for example to conduct Persistent XSS attacks or other persistent attacks. Best wishes & regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua

Hi MustLive, > In my article Classification of HTTP Response Splitting vulnerabilities HTTP Response Splitting isn't a vulnerability. It is an attack. The vulnerability is HTTP header injection. This is clear from your example: > http://site/page?p=%0AHeader:value You injected a header, you did not split the response into multiple responses. However, in the next example, you did do this: > http://site/page?p=%0AContent-Type:html%0A%0A%3Cscript%3Ealert(document.cookie)%3C/script%3E Note that to be technically correct, you should be using %0d%0a as your new lines. HTTP header injection can occur in requests and responses and response splitting is just one specific attack against one of those scenarios. Note that injecting simple headers without splitting responses can have a serious impact on security in specific scenarios. I think it is important to nail down correctly descriptive terminology so people have an easier time understanding the core issue. tim

On Mon, 21 Mar 2011, Tim wrote: > HTTP Response Splitting isn't a vulnerability. It is an attack. The > vulnerability is HTTP header injection. This is clear from your example: > >> http://site/page?p=%0AHeader:value > > You injected a header, you did not split the response into multiple > responses. I agree that "HTTP response splitting" is more of an attack than a vulnerability, but I still think the "HTTP header injection" term is attack-oriented - or, alternately, oriented towards "technical impact" or consequence (the attacker is "injecting" headers). The vulnerability is in allowing header-separator sequences (in this syntactic context, CRLF) to be entered into header metadata, stemming from a combination of one or more "weaknesses" typically involving missing/incorrect input validation, and/or missing/incorrect ouptput encoding (which depends on the specific code's implementation/design combined with the programmer's intention, and as indirectly influenced in interpretation of the core issue based on which fix is selected even though most vulns/weaknesses have multiple different potential fixes, which suggest that solely fix-oriented classification is also faulty.) > I think it is important to nail down correctly descriptive terminology > so people have an easier time understanding the core issue. I agree as well, but I think it's pretty difficult to get this stuff right, and to develop terminology that is supported, accessible, and understandable to all. Meanwhile there is the reality that catchy attack names often serve as the shorthand for the less-catchy-sounding errors that enable the attacks to take place. Just some food for thought :-) Collectively, we have a long way to go, and discussions like this can be informative. - Steve