Hi,

My website is vulnerable to XSS attack. How do i protect it from this attack?

P.S I want to safeguard the input from all known XSS attack located here

[ http://ha.ckers.org/xss.html ]

Thanks in advance --

Run htmlentities() when echoing input. What I do is create an ent() function in my header script:

function ent($str){
  return htmlspecialchars($str,ENT_QUOTES,'UTF-8');
}

Then when echoing, use it to sanitize each input:

echo '<h2>Search results for "'.ent($_GET['search']).'"</h2>'.LF;

The ent() function uses htmlspecialchars to convert the following tags:
< > " '
into safer entities:
&lt; &gt; &quot; &#39;

This should keep you safe as long as you don't echo user inputs into dynamic javascript code.

Thank you. I was looking for that anyway.

But one more thing, Is it possible to log whatever search term entered on my website?

If the search form uses $_GET, you can skim through your access_log. If it uses $_POST, you'll have to manually save the $_POST data. Most sites don't do that because it ends up using a whole bunch of server space.

I thought about that too. But this is an option, emailing the log-file when the size is 10mb and delete it for new entries

or you could match for certain things like HTML brackets in your post data, and only log that. An XSSer is bound to use these to test his XSS (obviously, they're not a requirement for XSS, but they are being used in any XSS test)

@Kyo

A clue will be nice.

@hackersa09 You can also use the PHPIDS - this will help you to not only detect XSS attacks but a lot or other patterns. Also the logging is pre-implemented and you can react on incoming attack attempts. So - no need to reinvent the wheel :)

Here's a forum post with a lot of links helping with installation and configuration.
http://forum.php-ids.org/comments.php?DiscussionID=232&page=1#Item_0



Edited 1 time(s). Last edit at 04/11/2009 07:38AM by .mario.

I've always wondered about the efficiency of using php-ids sitewide. Doesn't it rely on a lot of regex?

Kyo Wrote:
-------------------------------------------------------
> Doesn't it rely on a lot of regex?

lol

Yep - but it has a pre-check keeping most requests from being checked.

Indeed, it checks for alphanumeric. I guess that's a fairly clever way around the problem, but that's still at least one instance of regex per page. If (let's use a forum as example) my post contains a ', which many many posts do, or even a -, it'll run some more checks, and I guess what I'm getting at is that it can be quite heavy on the server if you get a lot of hits and aren't on the strongest server. Then again - that's kind of unavoidable with the nature of the IDs and if you get a lot of hits and aren't on the strongest server that problem isn't limited to PHP-IDS. Besides, you can always turn it off if it becomes a problem.

even though php-ids is a great solution, hackersa09 should fix his code first -- or maybe use php-ids as a temporary solution while he is fixing the code...

nEUrOO -- http://rgaucher.info -- http://twitter.com/rgaucher

Sure - he was just asking if it makes sense to re-invent a system detection malicious patterns... that just lit a lamp :)

Thats correct .mario.

I used the method you suggested:

function ent($str){
return htmlspecialchars($str,ENT_QUOTES,'UTF-8');
}

If I encounter any problem, I will surely alert everyone.

An understanding of the problem he is solving would certainly help, otherwise you end up with this;

http://twitter.com/i0n1c/status/1468716588

[www.justanotherhacker.com]

@wireghoul: +1 :)

ha ha, is that real?

Am beginning to wonder too. I was too scared to point that out though!

@Kyo,

Stefan is usually very sincere when it comes to security, so I have no doubt it is true. I've seen similar solutions myself. One of my personal favorites comes from an insurance agency I audited, their admin pages used to be protected with one of two techniques, from memory the snippets were similar to this:

The "YOU SAW NOTHING!" approach
<?php
if (!$_SESSION[admin]==1) {
echo "<script>window.close();</script>";
}
?>

and the "Charlie says LOGIN" approach
<?php
if(!$_SESSION[admin]==1) {
header("Location: login.php");
}
?>

Brilliant!

[www.justanotherhacker.com]

Ha ha, that's amazing. The second one doesn't really surprise me though. Many people don't realize that the content is still sent, even if you 301 them. I guess my funny story of the day is of a forum that did BBCode by simply replacing [ and ] with < and >. Yep, that's precisely what BBcode was made for. Users just hate those pointy brackets.

Be aware that not every client follows a header redirection, such as Netcat.

@ All

Lastly, a friend website was compromised a week ago. What happened was, whenever you type www.myfrienddomain.tld it shows, hacked by turkish hacker

My question is how did they manage to grab the username/password for the domain.

With the large amount of vulnerabilities that exist, it's impossible for us to
know how he came to deface your friends site with the information you provided.

honestly, you wouldn't even tell us the tld, lol. What do you think we're gonna do, try every com site out there 'till we find it?

No @ Kyo,

Don't take it like that. I think my question should have been is it possible for an attacker to deface the default page of a website using XSS technique??

@hackersa09: Usually not - most times they just utilize a vulnerability in some crappy 3rd party software and looking for a remote code execution/local file inclusion or similar. Don't consider those defacements as something smart - it just 5 minutes of googling to find sites where you can do that and a devastating urge to hang the own ****** out of the window.

XSS can only lead to defacement if it's on a site that has that power to deface the site in the admin panel (or if the admin has the same password as the FTP or similar), and even then it requires still interaction with an admin, directly or indirectly.

I get it now. Have a look at the below code:

var title = "This must be fixed";
var bgcolor = "#000000";
var image_url = "/images/vul.jpg";
var text = "Kindly take this seriously";
var font_color = "#FF0000";

deface(title, bgcolor, image_url, text, font_color);

function deface(pageTitle, bgColor, imageUrl, pageText, fontColor) {
document.title = pageTitle;
document.body.innerHTML = '';
document.bgColor = bgColor;
var overLay = document.createElement("div");
overLay.style.textAlign = 'center';
document.body.appendChild(overLay);
var txt = document.createElement("p");
txt.style.font = 'normal normal bold 36px Verdana';
txt.style.color = fontColor;
txt.innerHTML = pageText;
overLay.appendChild(txt);

if (image_url != "") {
var newImg = document.createElement("img");
newImg.setAttribute("border", '0');
newImg.setAttribute("src", imageUrl);
overLay.appendChild(newImg);
}

var footer = document.createElement("p");
footer.style.font = 'italic normal normal 12px Arial';
footer.style.color = '#DDDDDD';
footer.innerHTML = title;
overLay.appendChild(footer);
}

Yep, so say your friends website has a persistent XSS. By injecting that
JavaScript "permanently" on the website, it rewrites the web content to
make it appear as it has been defaced.