1

I have an ecommerce site which has to be PCI compliant. The issue I have is that it fails on a XSS attack:

www.mydomain.com?qs=%3c%2fscript%3e%3c script%3ealert(12345)%3c%2fscript%3e

Is there a way in .htaccess to strip out any malicious script tags and redirect the user to another page? Or am I barking up the wrong tree?

Sameera Thilakasiri
  • 9,452
  • 10
  • 51
  • 86
user180386
  • 88
  • 1
  • 2
  • 8

4 Answers4

3

The best approach would be to not trust user input in your code. For example, never echo user-provided data back to the browser without running it through htmlspecialchars or similar. This is in the same category as SQL injection attacks, except that the injection is targeted at the generated HTML code and not the SQL query.

User-provided data is all data that may be tampered with from the client side. This includes: $_POST, $_GET, file uploads, cookies and HTTP headers (like User-Agent and Referer). Such data must always be treated as untrusted and needs to be secured for each context. Are you going to insert the data into a database? Escape the data before putting it into your query (or use prepared statements)! Are you going to output it to the user's browser? Escape with htmlspecialchars! Is it supposed to be an e-mail address? Make sure it actually is before inserting into an e-mail message!

Note that the data may be unsecure for some contexts even if you save it into a database. For example, $_POST data properly SQL-escaped may still contain HTML tags or other XSS data, so it will need to be escaped before it gets sent to the browser (what I'm trying to say here is that the user-provided label doesn't go away just because you save the data in a database or to a file). A good way to protect against this is to do escaping for each context as late as possible (e.g., htmlspecialchars just before you echo) to make sure that the escaping method used is the correct one for this context, but also to do validation as early as possible (don't accept invalid data in the first place, e.g., validate e-mail addresses and throw an error if it's invalid).

There's also the ModSecurity extension for Apache which will catch most of these attacks, but it's not foolproof because there are almost endless ways to craft an injection. ModSecurity should therefore only be used when you already have secured your application code but are afraid that you may miss something due to bugs in the future (which may happen to most of us in some way or another).

Emil Vikström
  • 90,431
  • 16
  • 141
  • 175
1

Why don't you clean up the $_GET variable in the code?

Shomz
  • 37,421
  • 4
  • 57
  • 85
0

Yes I do believe so. Found at http://www.simonecarletti.com/blog/2009/01/apache-query-string-redirects/

RewriteEngine On
RewriteCond %{REQUEST_URI}  ^/page\.php$
RewriteCond %{QUERY_STRING} ^id=([0-9]*)$
RewriteRule ^(.*)$ http://mydomain.site/page/%1.pdf [R=302,L]

Notice the regular expressions. This should mean you can design your regex to accomidate the things you are trying to prevent. Google regex reference and see tons of them.

Remember that htaccess file will affect any directory its located and all sub-directories. There are a lot of good .htaccess tips here including the redirect http://www.sitepoint.com/htaccess-for-all/

JSG
  • 390
  • 1
  • 4
  • 13
0

Check to see if the following htaccess method help in your case http://wp-mix.com/block-xss-htaccess/

Vincent
  • 1
  • 1