Some of the websites in the Review Websites forum are vulnerable to various forms of attacks. One of them is called a Cross-Site Scripting attack, or XSS. Here's how it works: a) an inexperienced webmaster hosts a page that echoes back form arguments; b) a hacker sends an email that contains specially crafted arguments to a victim; c) the victim clicks on the link and goes to the website, which echoes back attacker's arguments to the victim; d) victim's browsers executes the attacker's code, while still being connected to the target website - hence the name of the attack. Here's a little example for everybody to understand this better. Copy form.php into any directory on your website. This file will represent a login form on your website. Copy login.html into the same directory. This is the email the victim receives. Now, type anything in the input field and submit the form. As you can see, everything works as expected and you get your text echoed back. Open login.html in the browser and click on the link. Once you get the form, type anything you want and click submit. See the difference? Only in real life, there will be no friendly DP site, it will be a hacker gathering your customer's credentials. Check your input! J.D.
I don't think posting so much detail about this is a good idea... Last thing we need are newbies and kids testing this out
They already know. Anyway, I changed the post and attached all examples as files. I will remove them after a while. J.D.
Phishing is usually a fake site used to hopefully gain real information on another (usually financial) website. For example, I get emails all the time asking me to verify my Paypal account (which is sent to the incorrect email address), my Washington Mutual account (which I do not have), and a lot of other financial institutions.
I actually almost fell once for one of those fake Paypal emails. When I got to the fake page, I forgot my paypal password!!! lol, I was just so damn lucky.
Here's a few articles about phishing: http://news.netcraft.com/cgi-bin/search.cgi?IncludeBlogs=1&search=phish J.D.
Yes fryman you were very luck. Scary thing is - I was actually having problems with my Paypal account one day and I received one. Fortunately for me whoever created the website really screwed up on the layout. The Paypal phishing sites can be pretty bad about a quick drain to your paypal account - it's those bank account ones that really can screw one over
You mean that <?= rawurlencode("test\"<script>somescripthere;</script><p \"") ?> PHP: will be submitted as text first and then executed/parsed by form.php ? It wouldn't 'work' on my site so I guess that's a good thing. I always try to strip input from all html/php but I have to say I'mm not as 'creative' with security issues as I probably should be. J.D. do you have some links to articles which discuss common holes in php? As a sort of check list for us?
No, not really. The code in the second file will be executed by the visitor's browser. Run this test and once you click on the link, look at the generated HTML source. You will see the problem. The input should always be checked immediately after it's received or encoded before it is echoed back. In the first case regular expressions may be used to make sure the input doesn't have any unexpected characters; in the second case some encoding function, such as htmlspecialchars, should be used to encode the input (depending on where you want to echo the input). TOPS, do you mind removing this quote from your post (see fryman's and my comments after my post)? J.D.
Looking at your post I just realized - I forgot to rename the second file. It's supposed to be a PHP file, not HTML (i.e. should be login.php). I can't edit that post anymore to fix this, so just rename the file after you download it. Of course, it doesn't have to be PHP - in real life you would receive the HTML it generates. I just used the encoding function to make it easier for everybody to see the actual code (otherwise it would be too cryptic). This particular problem is not a hole in PHP. It's a coding problem. J.D.
I rarely use forms but I'm starting to delete troublesome substrings, such as <?, etc. after the data has been sent. Is that enough? Or is there another layer of protection that I need to worry about?
There are two cases to worry about - input and output. Validate the input (e.g. if you expect a number, make sure the value is actually a number) and encode the output (e.g. use HTML or URL encoding functions before echoing any variables that were populated using user input). For example, if you expect alphanumeric input, do this: if(eregi("^[0-9A-Z]{1,32}$", $input)) // valid non-empty input (up to 32 chars) else // invalid input PHP: When echoing HTML, use htmlspecialchars. This will take care of things like <script> passed with the input. Use encoding wisely, though - if you pass input values to the database, encoding input will break your database apps (say, if you are looking for a string with a '<' in it). J.D.
strip_tags is damn handy, I always use it on any user input that'll be later displayed anywhere on the site.
Regex provides a more generic mechanism, as it allows you to control what exactly you allow the input to be. For example, the code above will restrict the input to 32 alphanumeric characters maximum, which is something a stimple strip function won't do. J.D.
Fair enough, but for the purpose of neutralising x-site scripting attacks, isn't stripping tags enough?
In most cases, yes it will do the job. You have to be careful where to apply it, though. Say, if the data is encoded in some way so that tags don't appear as tags and then later decoded in your code before it's echoed back, it may still be dangerous. Another problem with this is that sometimes you do want encoded tags to appear in the output, in which case you need to HTML-encode them instead of stripping. For example, if you want to echo a query of some kind (e.g. full-text search) that may contain <>'s. Finally, the input may contain other dangerous characters that are not tags (e.g. header-splitting attacks come to mind). J.D.
Youch, just looked up header splitting, damn cookies Thanks for your insight I'm going to take it on board...