<div><h3 title="Vivensas.FASOFT.App/ReportView/ReportViewerPage.aspx.cs : 156" style="box-sizing:border-box;margin:0px 15px 8px 0px;font-weight:500;font-size:24px;text-overflow:ellipsis;overflow:hidden;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><span style="box-sizing:border-box;">Vivensas.FASOFT.App/ReportView/ReportViewerPage.aspx.cs : 156</span> </h3><h3 style="box-sizing:border-box;margin:0px 15px 8px 0px;font-weight:500;font-size:24px;text-overflow:ellipsis;overflow:hidden;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;">Summary </h3><p style="box-sizing:border-box;margin-top:0px;margin-bottom:1rem;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"> </p><h3 style="box-sizing:border-box;margin:0px 15px 8px 0px;font-weight:500;font-size:24px;text-overflow:ellipsis;overflow:hidden;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;">Explanation </h3><p style="box-sizing:border-box;margin-top:0px;margin-bottom:1rem;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;">Header Manipulation vulnerabilities occur when:<br style="box-sizing:border-box;"><br style="box-sizing:border-box;">1. Data enters a web application through an untrusted source, most frequently an HTTP request.<br style="box-sizing:border-box;"><br style="box-sizing:border-box;"><br style="box-sizing:border-box;">2. The data is included in an HTTP response header sent to a web user without being validated.<br style="box-sizing:border-box;"><br style="box-sizing:border-box;">As with many software security vulnerabilities, Header Manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header.<br style="box-sizing:border-box;"><br style="box-sizing:border-box;">One of the most common Header Manipulation attacks is HTTP Response Splitting. To mount a successful HTTP Response Splitting exploit, the application must allow input that contains CR (carriage return, also given by %0d or \r) and LF (line feed, also given by %0a or \n)characters into the header. These characters not only give attackers control of the remaining headers and body of the response the application intends to send, but also allows them to create additional responses entirely under their control.<br style="box-sizing:border-box;"><br style="box-sizing:border-box;">Many of today's modern application servers and frameworks will prevent the injection of malicious characters into HTTP headers. For example, recent versions of Microsoft's .NET framework will convert CR, LF, and NULL characters to %0d, %0a and %00 when they are sent to the<span>&nbsp;</span><code style="box-sizing:border-box;font-family:SFMono-Regular, Menlo, Monaco, Consolas, &quot;Liberation Mono&quot;, &quot;Courier New&quot;, monospace;font-size:12.25px;color:rgb(225, 31, 38);background-color:rgb(241, 242, 243);border-radius:0px;">HttpResponse.AddHeader()</code><span>&nbsp;</span>method. If you are using the latest .NET framework that prevents setting headers with new line characters, then your application might not be vulnerable to HTTP Response Splitting. However, solely filtering for new line characters can leave an application vulnerable to Cookie Manipulation or Open Redirects, so care must still be taken when setting HTTP headers with user input.<br style="box-sizing:border-box;"><br style="box-sizing:border-box;"><b style="box-sizing:border-box;font-weight:bolder;">Example 1:</b><span>&nbsp;</span>The following code segment reads the name of the author of a weblog entry,<span>&nbsp;</span><code style="box-sizing:border-box;font-family:SFMono-Regular, Menlo, Monaco, Consolas, &quot;Liberation Mono&quot;, &quot;Courier New&quot;, monospace;font-size:12.25px;color:rgb(225, 31, 38);background-color:rgb(241, 242, 243);border-radius:0px;">author</code>, from an HTTP request and sets it in a cookie header of an HTTP response.<br style="box-sizing:border-box;"><br style="box-sizing:border-box;"></p><pre style="box-sizing:border-box;font-family:SFMono-Regular, Menlo, Monaco, Consolas, &quot;Liberation Mono&quot;, &quot;Courier New&quot;, monospace;font-size:12.25px;margin-top:0px;margin-bottom:1rem;overflow:auto;display:block;border-radius:0px;background-color:rgb(245, 247, 248);border-color:rgb(241, 242, 243);text-align:left;">  <br style="box-sizing:border-box;">protected System.Web.UI.WebControls.TextBox Author;<br style="box-sizing:border-box;">...<br style="box-sizing:border-box;">string author = Author.Text;<br style="box-sizing:border-box;">Cookie cookie = new Cookie(&quot;author&quot;, author);<br style="box-sizing:border-box;">...<br style="box-sizing:border-box;"></pre><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><span style="font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;display:inline !important;">Assuming a string consisting of standard alphanumeric characters, such as &quot;Jane Smith&quot;, is submitted in the request the HTTP response including this cookie might take the following form:</span><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><pre style="box-sizing:border-box;font-family:SFMono-Regular, Menlo, Monaco, Consolas, &quot;Liberation Mono&quot;, &quot;Courier New&quot;, monospace;font-size:12.25px;margin-top:0px;margin-bottom:1rem;overflow:auto;display:block;border-radius:0px;background-color:rgb(245, 247, 248);border-color:rgb(241, 242, 243);text-align:left;">  <br style="box-sizing:border-box;">HTTP/1.1 200 OK<br style="box-sizing:border-box;">...<br style="box-sizing:border-box;">Set-Cookie: author=Jane Smith<br style="box-sizing:border-box;">...<br style="box-sizing:border-box;"></pre><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><span style="font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;display:inline !important;">However, because the value of the cookie is formed of unvalidated user input the response will only maintain this form if the value submitted for<span>&nbsp;</span></span><code style="box-sizing:border-box;font-family:SFMono-Regular, Menlo, Monaco, Consolas, &quot;Liberation Mono&quot;, &quot;Courier New&quot;, monospace;font-size:12.25px;color:rgb(225, 31, 38);background-color:rgb(241, 242, 243);border-radius:0px;text-align:left;">Author.Text</code><span style="font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;display:inline !important;"><span>&nbsp;</span>does not contain any CR and LF characters. If an attacker submits a malicious string, such as &quot;Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...&quot;, then the HTTP response would be split into two responses of the following form:</span><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><pre style="box-sizing:border-box;font-family:SFMono-Regular, Menlo, Monaco, Consolas, &quot;Liberation Mono&quot;, &quot;Courier New&quot;, monospace;font-size:12.25px;margin-top:0px;margin-bottom:1rem;overflow:auto;display:block;border-radius:0px;background-color:rgb(245, 247, 248);border-color:rgb(241, 242, 243);text-align:left;">  <br style="box-sizing:border-box;">HTTP/1.1 200 OK<br style="box-sizing:border-box;">...<br style="box-sizing:border-box;">Set-Cookie: author=Wiley Hacker<br style="box-sizing:border-box;"><br style="box-sizing:border-box;">HTTP/1.1 200 OK<br style="box-sizing:border-box;">...<br style="box-sizing:border-box;"></pre><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><span style="font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;display:inline !important;">Clearly, the second response is completely controlled by the attacker and can be constructed with any header and body content desired. The ability of attacker to construct arbitrary HTTP responses permits a variety of resulting attacks, including: cross-user defacement, web and browser cache poisoning, cross-site scripting, and page hijacking.</span><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><b style="box-sizing:border-box;font-weight:bolder;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;">Cross-User Defacement:</b><span style="font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;display:inline !important;"><span>&nbsp;</span>An attacker will be able to make a single request to a vulnerable server that will cause the server to create two responses, the second of which may be misinterpreted as a response to a different request, possibly one made by another user sharing the same TCP connection with the server. This can be accomplished by convincing the user to submit the malicious request themselves, or remotely in situations where the attacker and the user share a common TCP connection to the server, such as a shared proxy server. In the best case, an attacker may leverage this ability to convince users that the application has been hacked, causing users to lose confidence in the security of the application. In the worst case, an attacker may provide specially crafted content designed to mimic the behavior of the application but redirect private information, such as account numbers and passwords, back to the attacker.</span><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><b style="box-sizing:border-box;font-weight:bolder;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;">Cache Poisoning:</b><span style="font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;display:inline !important;"><span>&nbsp;</span>The impact of a maliciously constructed response can be magnified if it is cached either by a web cache used by multiple users or even the browser cache of a single user. If a response is cached in a shared web cache, such as those commonly found in proxy servers, then all users of that cache will continue receive the malicious content until the cache entry is purged. Similarly, if the response is cached in the browser of an individual user, then that user will continue to receive the malicious content until the cache entry is purged, although only the user of the local browser instance will be affected.</span><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><b style="box-sizing:border-box;font-weight:bolder;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;">Cross-Site Scripting:</b><span style="font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;display:inline !important;"><span>&nbsp;</span>Once attackers have control of the responses sent by an application, they have a choice of a variety of malicious content to provide users. Cross-site scripting is common form of attack where malicious JavaScript or other code included in a response is executed in the user's browser. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site. The most common and dangerous attack vector against users of a vulnerable application uses JavaScript to transmit session and authentication information back to the attacker who can then take complete control of the victim's account.</span><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><b style="box-sizing:border-box;font-weight:bolder;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;">Page Hijacking:</b><span style="font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;display:inline !important;"><span>&nbsp;</span>In addition to using a vulnerable application to send malicious content to a user, the same root vulnerability can also be leveraged to redirect sensitive content generated by the server and intended for the user to the attacker instead. By submitting a request that results in two responses, the intended response from the server and the response generated by the attacker, an attacker may cause an intermediate node, such as a shared proxy server, to misdirect a response generated by the server for the user to the attacker. Because the request made by the attacker generates two responses, the first is interpreted as a response to the attacker's request, while the second remains in limbo. When the user makes a legitimate request through the same TCP connection, the attacker's request is already waiting and is interpreted as a response to the victim's request. The attacker then sends a second request to the server, to which the proxy server responds with the server generated request intended for the victim, thereby compromising any sensitive information in the headers or body of the response intended for the victim.</span><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><b style="box-sizing:border-box;font-weight:bolder;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;">Cookie Manipulation:</b><span style="font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;display:inline !important;"><span>&nbsp;</span>When combined with attacks like Cross-Site Request Forgery, attackers may change, add to, or even overwrite a legitimate user's cookies.</span><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><br style="box-sizing:border-box;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;"><b style="box-sizing:border-box;font-weight:bolder;font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;">Open Redirect:</b><span style="font-family:Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif;text-align:left;display:inline !important;"><span>&nbsp;</span>Allowing unvalidated input to control the URL used in a redirect can aid phishing attacks.</span><br></div>