[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3F1E072C.9060806@snosoft.com>
From: dotslash at snosoft.com (KF)
Subject: logically stopping xss
some random text about mod_security I forget where it came from maybe a
security focus article...
*Defending against CSS and SQL Injection attacks*
The last step of securing the server is implementing the logging of the
GET and POST payloads, and implementing protection against
Cross-Site-Scripting and SQL Injection attacks. In order to perform
that, we will use the mod_security module, which we enable by adding the
following line into httpd.conf:
AddModule mod_security.c
To enable logging of the GET and POST requests, it suffices to add the
following section to httpd.conf:
<IfModule mod_security.c>
AddHandler application/x-httpd-php .php
SecAuditEngine On
SecAuditLog logs/audit_log
SecFilterScanPOST On
SecFilterEngine On
</IfModule>
The above commands will enable the Audit Engine, which is responsible
for logging requests, and the Filtering POST Engine, which will make it
possible to log POST requests. In order to protect web application
against CSS attacks, the following lines should also be inserted before
"</IfModule>":
SecFilterDefaultAction "deny,log,status:500"
SecFilter "<(.|\n)+>"
The first line causes that the server to return the "Internal Server
Error" message when the request contains the search phrase from any
SecFilter variable. The second line sets up the filter to search for
HTML tags in the GET and POST requests.
One of the typical signatures of SQL Injection attack is the appearance
of an apostrophe (') or quotation mark (") in the GET or POST request.
By rejecting all the requests containing those characters, we can make
the use of SQL Injection technique very difficult:
SecFilter "'"
SecFilter "\""
Note, that although filtering the <, >, ', " characters lets us defend
against CSS and SQL Injection attacks, it can lead to the improper
functioning of the PHP application. It happens, because regular users
cannot use those characters in the HTML forms. To solve that problem,
the JavaScript language can be used on the client side, which should
replace the prohibited characters with special tags, e.g. < >
" etc.
-KF
Justin Shin wrote:
>see theres a gazillion xss "exploits" just sitting out there that no-one knows of, and no admin can keep up with all the new "exploits" for xss. I am just looking for suggestions, that's all. I swear, when I said was stupid, I didn't mean I was THAT stupid :)
>
>-- Justin Shin
>
>-----Original Message-----
>From: Valdis.Kletnieks@...edu [mailto:Valdis.Kletnieks@...edu]
>Sent: Tuesday, July 22, 2003 11:05 PM
>To: Justin Shin
>Cc: Full-Disclosure@...ts.Netsys.Com
>Subject: Re: [Full-Disclosure] logically stopping xss
>
>
>On Tue, 22 Jul 2003 21:33:00 EDT, Justin Shin <zorkshin@...pabay.rr.com> said:
>
>
>
>>i know there's a lot of stupid jokes about XSS vulns right now, but I was
>>wondering if there is any firewall or IDS software that can look for suspicious
>>GET requests ... ie.
>>
>>
>
>
>
>>GET /vulnerablewebapp/?<XSS SHZNIT>
>>
>>
>
>
>
>>I'm sure there's a program out there ... and I'm stupid, please don't kill me
>>
>>
>
>SNORT comes with a pretty long list....
>
>
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>
>
Powered by blists - more mailing lists