AttackFlow Findings Dictionary

Finding A Way To Try AttackFlow Enterprise Edition?

If so, click to download 15 days full version for free!

Reflected Cross Site Scripting

The attacker can send crafted script payloads into the application and steal end-users credentials by making application showing them fake, rouge interfaces or HTML.

Severity

High

Fix Cost

Low

Trust Level

High

Cross site scripting (XSS) is somewhat a controversial web application vulnerability type. Some claim that XSS is “the next buffer overflow vulnerabilities”, the others claim that prevention is nothing but a waste of time since little damage can be done by an attacker exploiting an XSS vulnerability.

No matter the perspective you are looking with, it is wise to prevent XSS vulnerabilities since under certain conditions this weakness can result in complete ownage of the target system, such as certain XSS weaknesses in WordPress content management system.

There are more than one type of XSS attacks, mainly;

  • Reflected XSS
  • Stored XSS
  • Dom-based XSS

But at the heart of the problem stems from outputting untrusted user data into the HTML.

Let the backend code is similar to the following snippet;

                           
protected void Button1_Click(object sender, EventArgs e)
{
Label1.Text = TextBox1.Text;
}
                 
            

For example, by sending <script>prompt(1)</script> as TextBox1 HTTP parameter, the attacker may execute the script of his choosing in the browser and more importantly under the target application’s domain (URL). Being able to execute random javascript in browsers under the target domain bypasses every Same Origin Policy (SOP) related limitations that browsers enforce. When SOP is bypassed this way, attacker’s javascript may steal current end-user’s cookies, show fake HTML interfaces, send and receive HTTP requests to the target application.

The way that the attacker makes the end-user to click a link, or open a target web application is outside of the scope, however, there are very persuasive ways of pulling these off.

Every injection attack occurs because of mixing code and untrusted data in the code. As developers, we are rarely provided secure APIs in order to keep these two information (code and data) apart, until the runtime. In the above code, mixing the data, as TextBox1 coming from the user, and code, as the partial HTML code in the code behind, result in XSS. The attacker can potentially manipulate the produced HTML and access the information that he can’t access otherwise.

Finding A Way To Purchase AttackFlow Enterprise Edition?

If so, click to buy now for yearly subscriptions!