[BreShiE]

This post is leaked from the premium section of "Legion" on the competing hack forum. There will be 5 new leaks a day. There may be some format problems due to UTF8 character encoding.

Persistent XSS how does it work?

Basically XSS is arbitary code injected into a page that should be in fact sanitized with PHP security functions. With non persistent XSS it tends to simply be reflected back in a variable via POST or GET but its input is not saved, this can lead to cookie stealing but requires further manipulation by the attacker to social engineering users or use BeEF or set up landing pages which can be a tad more complex.

In this example I will show how a persistent XSS actually takes place and what leads to its input being saved via bad coding practices.

I will conduct this test localhost.

Vulnerable script:

PHP Code:

<form action="#" method="POST"> //POST method via form <b>Enter your name:</b><br> // Simple HTML - what the user sees <input type="text" name="name"><br> //text box and form "name" will have data collected from $_POST['name'] <input type="submit" value="Submit"><br> //submit button stating Submit to user <br> </form> //end form <?php //begin php if(!empty($_POST['name'])){ //if the html text box is not empty and has received input $filename = "xss.shtml"; //assign this file name to the variable $file = fopen($filename, 'w') or die ("File couldn't be opened!"); //open the file for writing, if not give error $text = "Input has been saved ".$_POST['name']."!"; //assign the message to the $text variable with the users input name data fwrite($file, $text); //write the information above to the file xss.shtml fclose($file); //close file print '<a href="xss.shtml">Click Here To View!</a>'; //create a a href link to the xss.shtml file where our data is contained } ?>

I commented out the script above in the simplest way that I possibly could. What this script does is take our input and save it to a file, sounds innocent? Well some of you may have noticed that the input is in no way stripped and malicious code can be and alert boxes triggered and cookies stolen etc.

Lets use it the innocent way first:



And submit then view:



Now lets take it from a malicious point of view, lets add some Javascript to it and attempt an XSS:



If you have been following, this will be write to a file for viewing. Lets view the file and see the result:



This is the poor code snippet that has caused this attack to be successful:

PHP Code:

if(!empty($_POST['name'])){ $filename = "xss.shtml"; $file = fopen($filename, 'w') or die ("File couldn't be opened!"); $text = "Input has been saved ".$_POST['name']."!"; fwrite($file, $text); fclose($file); print '<a href="xss.shtml">Click Here To View!</a>'; }

As I explained before, no user input is being stripped and dangerous characters will be allowed. This can be prevented via the use of PHP's security functions, in this case we will use htmlentities()

PHP Code:

<form action="#" method="POST"> <b>Enter your name:</b><br> <input type="text" name="name"><br> <input type="submit" value="Submit"><br> <br> </form> <?php if(!empty($_POST['name'])){ $filename = "xss.shtml"; $file = fopen($filename, 'w') or die ("File couldn't be opened!"); $text = "Input has been saved " .htmlentities($_POST['name']."!"); fwrite($file, $text); fclose($file); print '<a href="xss.shtml">Click Here To View!</a>'; } ?>

Lets now test with the exact same procedure as before:

Submit our XSS vector into the box again:



Result:



No pop up occured, and if we check the source we will see that the majority of our characters have been automatically converted to prevent the attack from being successful:



This is the basics behind a persistent XSS attack. Exactly the reason why people will advise to target guestbooks and other forms of methods that are designed to receive and store user input.

As I have demonstrated that if input is not being stripped nor sanitized then your vulnerable to attack with fatal repercussions. Any half decent programmer will use these security functions when receiving user input. Same goes for SQL and the mysql_real_escape_string function that escapes user input and prevents the queries from successfully withdrawing data from the DB, although PDO has been introduced with its own precautions as mysql has become deprecated

This tutorial was as noob friendly as I could possibly make it. Hope you enjoyed reading, VV. :blackhat: