prevent xss atack

[funbinod]

can anyone suggest what is the best method to prevent xss attacks! is using " mysqli_real_escape_string " enough for this?? please guide in detail...

[Ingolme]

The best method is to use prepared statements:

MySQLi http://ca1.php.net/manual/en/mysqli.quickstart.prepared-statements.php

PDO http://ca1.php.net/manual/en/pdo.prepared-statements.php

[justsomeguy]

Prepared statements and escaping just prevent SQL injection. If you're trying to protect against XSS attacks then that means not printing things on the page that could contain user-supplied Javascript code. Maybe you run it through a filter that removes Javascript from submitted text, or maybe you escape HTML characters when printing user-supplied text, etc.

[funbinod]

 

Maybe you run it through a filter that removes Javascript from submitted text, or maybe you escape HTML characters when printing user-supplied text, etc.

can u please define this with some example....

 

Prepared statements and escaping just prevent SQL injection

and can escaping characters work fine as prepared statements???

[justsomeguy]

You can use HTMLPurifier to remove Javascript, among other things.http://htmlpurifier.org

and can escaping characters work fine as prepared statements???

Escaping characters and prepared statements don't have anything to do with each other. Prepared statements are for interacting with the database, escaping characters comes into play when you display something on the page.

[funbinod]

isn't this for storing to database....????

$username = mysqli_real_escape_string($connect, $_POST['username'])mysqli_query($connect, "INSERT INTO user (username) VALUES ('$username')");

[justsomeguy]

Yes. I would suggest using prepared statements there instead of manually escaping the value but yeah, that's for storing to a database. I was suggesting that escaping is not necessary when you use prepared statements, that's one of the purposes of using prepared statements.

[funbinod]

or would u give me green signal if I just used escaping characters but not prepared statements?

 

and please define differences between mysqli_real_escape_string() and htmlspecialchars() along with the use of trim()....

[justsomeguy]

or would u give me green signal if I just used escaping characters but not prepared statements?

Manually escaping leaves too much room for error. Prepared statements are the best practice.

and please define differences between mysqli_real_escape_string() and htmlspecialchars() along with the use of trim()....

Mysqli_real_escape_string adds slashes before certain characters. According to the manual...

Characters encoded are NUL (ASCII 0), n, r, , ', ", and Control-Z.

htmlspecialchars encodes certain characters as their corresponding HTML entities, and trim removes whitespace at the beginning and ending of a string. You can look up the documentation for all of those functions to see what they do.

[funbinod]

that means htmlspecialchars() will convert <script> to &ldscript&gd !!!???? or anything else? is there any idea to stop activity if it found <script> or such elements...????

[davej]

See...

 

https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet#XSS_Cheat_Sheet

 

and

 

https://www.owasp.org/index.php/XSS

[funbinod]

how is it to use php-antixss??

[funbinod]

was my last question unclear???

 

i was asking - is using PHP-Antixss good? will it protect from every type of XSS attack?

[justsomeguy]

I've never heard of it. Like anything else, it's a tool. If you use it correctly it may help. If you don't use it correctly it won't help. If you're looking for one piece of code you can add that will magically protect your entire site from every kind of attack, you won't find it. The only way to guarantee no XSS attacks is to not show any user-submitted data on your site.

[JamesB]

The only way to guarantee no XSS attacks is to not show any user-submitted data on your site.

Surely one could use htmlspecialchars() for user submitted data to guarantee no xss attacks too right?

[justsomeguy]

I don't know.. could they? Is it that simple?It all depends on what you're doing with the data. There are a ton of different ways to perform XSS attacks, many of them using malformed HTML and Javascript, or attribute values, some that use no special characters at all depending on the context. And what if you're giving your users a rich text editor where they can submit tags or HTML directly? You can't just escape everything because you would break the formatting. Look at a list of the possible ways that people try to avoid XSS filters:https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_SheetEscaping special HTML characters can go a long way, but the point I'm trying to make is that it is not the one thing you do in order to stop all XSS attacks in every situation. It may work for many common purposes though, assuming you use it everywhere.https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet#XSS_Cheat_Sheet

If you are using standard PHP for templating, or `echo` etc., then you can mitigate XSS in this case by applying 'htmlspecialchars' to the data, or the following function (which is essentially a more convenient wrapper around 'htmlspecialchars'). However, this is not recommended. The problem is that you have to remember to apply it every time, and if you forget once, you have an XSS vulnerability. Methodologies that are insecure by default must be treated as insecure.Instead of this, you should use a template engine that applies HTML escaping by default - see below. All HTML should be passed out through the template engine.

[JamesB]

Interesting, but I'm sure its possible to protect against every type of xss attack somehow.

[Ingolme]

You can't guarantee that there's something you didn't think about. Even in large websites vulnerabilities are sometimes discovered in unexpected ways. You can be 99.99% sure, but never 100% sure.

 

Allowing user input is a risk that has to be taken, of course. But it's true that the only way to absolutely guarantee no XSS attacks is to not show anything provided by a user on the website.

[justsomeguy]

Interesting, but I'm sure its possible to protect against every type of xss attack somehow.

You can go through the list of ways and find places where your application is vulnerable and fix them, sure, but you wouldn't necessarily use the same fix in every situation.

[JamesB]

You can go through the list of ways and find places where your application is vulnerable and fix them, sure, but you wouldn't necessarily use the same fix in every situation.

 

Fair enough.

 

 

 

You can't guarantee that there's something you didn't think about.

 

Well I sort of disagree. I mean I know its very easy to forget a htmlspecialchars() hear and there, but say if someone was making an API, they could check the SGML/XML spec and make sure every byte code is valid in it's place.

[justsomeguy]

Again though, there are several situations to consider. What if your website has an HTML editor, where HTML is explicitly allowed? In that case you can't just escape everything, in that case you need to parse the code and strip out things that shouldn't be there. So, you need rules for what to strip out or what to allow. If you have a whitelist that's good, a whitelist is much more secure than a blacklist. If you're using regular expressions or something like that then there are several things that are perfectly legal which you might not consider or even be aware of, like this:

<IMG SRC=`javascript:alert("RSnake says, 'XSS'")`>

Those are not quotes surrounding the src attribute, and they're perfectly legal.Or malformed things:

<IMG """><SCRIPT>alert("XSS")</SCRIPT>">

Or this:

<IMG SRC=javascript:alert(String.fromCharCode(88,83,83))>

or this:

<IMG SRC=/ onerror="alert(String.fromCharCode(88,83,83))"></img>

Or these:

<IMG SRC=javascript:alert('XSS')><IMG SRC=javascript:alert('XSS')><IMG SRC=javascript:alert('XSS')><IMG SRC="javascript:alert('XSS');"><SCRIPT/XSS SRC="http://ha.ckers.org/xss.js"></SCRIPT><BODY onload!#$%&()*~+-_.,:;?@[/|]^`=alert("XSS")><STYLE>li {list-style-image: url("javascript:alert('XSS')");}</STYLE><UL><LI>XSS</br><STYLE>@import'http://ha.ckers.org/xss.css';</STYLE><STYLE>@import'javascript:alert("XSS")';</STYLE><META HTTP-EQUIV="refresh" CONTENT="0;url=data:text/html base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K">

You know what I'm saying? There are a ton of ways for people to attack a site. The major way to limit those possible attacks is to limit how people interact with your site. 100% protection is very difficult. You might want to use something like HTMLPurifier to parse the HTML and return a cleaned version, but again, you're relying on a parsing algorithm that would be able to remove things like the above. It's hard to be 100% certain about any of this stuff, but it doesn't hurt to be aware of it and incorporate it into your design.

[JamesB]

I agree that it would be very difficult to prevent against every xss attack in specialist situations like a HTML editor. But I still think with enough time and thought spent on something it can be 100% hack free.

[Don E]

Don't mean to intervene... I basically just did a <script>alert('hello world');</script> on Facebook for experimenting and looked in the source to see what the output was, it came back just as <script>alert('hello world');</script> inside <p> tag. I wasn't aware by allowing HTML tags in a HTML document without being converted to specialchars or anything can appear just as is with no effect taking place? Yes I know its Facebook and they probably have a team of people that work on user submitted stuff alone but found that interesting.

[justsomeguy]

In theory, sure. In practice, you're relying on so many third-party tools that any one of them might have a vulnerability that is out of your control. PHP itself might have a vulnerability, or the web server, or OpenSSL, or maybe you just decided to implement a "security question" and people find out your users' answers and download all of their naked pictures. Or maybe it has nothing to do with you, and some router somewhere down the line is intercepting traffic to your site and changing the response to inject their own code onto your pages and attack your users.PHP has somewhat of a bad reputation in security circles because of all of the terrible code splashed all over the internet in various tutorials. You can still find people writing tutorials today teaching people to use the mysql extension to interact with the database, and for some people reason act surprised when Russian hackers steal 1.2 billion sets of usernames and passwords through SQL injection vulnerabilities (still the #1 vulnerability, here in 2014). There are other companies, including billion dollar banks, who hire programmers that don't understand the difference between authentication and authorization. Governments are hacking other governments. Linux machines are being infected and added to massive botnets. Security is great in theory, but in practice 100% security is very difficult to achieve. There are so many other pieces in play other than just the code you write.

[justsomeguy]

I wasn't aware by allowing HTML tags in a HTML document without being converted to specialchars or anything can appear just as is with no effect taking place?

It's loaded through ajax. When you add HTML content to a page via Javascript it will not execute Javascript code inside that HTML content.