|
|||
|
a mod_security rule is breaking one script on one account
One of my customers has a shopping cart script which as an element that calls to to a "user_password.js" javascript file.
mod_security is preventing that file from operating, giving it a 406 denial. I have discovered the mod_security rule that is causing this, the particular part highlighted in bold: Code:
# Blind SQL injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "(?:\b(?:(?:s(?:ys\.(?:user_(?:(?:t(?:ab(?:_column|le)|rigger)|object|view)s|c(?:onstraints|atalog))|all_tables|tab)|elect\b.{0,40}\b(?:substring|ascii|user))|m(?:sys(?:(?:queri|ac)e|relationship|column|object)s|ysql.user)|c(?:onstraint_type|harindex)|attnotnull)\b|(?:locate|instr)\W+\()|\@\@spid\b)" \
"capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'Blind SQL Injection Attack. Matched signature <%{TX.0}>',id:'950007',severity:'2'"
SecRule REQUEST_FILENAME|ARGS|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "\b(?:(?:s(?:ys(?:(?:(?:process|tabl)e|filegroup|object)s|c(?:o(?:nstraint|lumn)s|at)|dba|ibm)|ubstr(?:ing)?)|user_(?:(?:(?:constrain|objec)t|tab(?:_column|le)|ind_column|user)s|password|group)|a(?:tt(?:rel|typ)id|ll_objects)|object_(?:(?:nam|typ)e|id)|pg_(?:attribute|class)|column_(?:name|id)|(?:dba|mb)_users|xtype\W+\bchar|rownum)\b|t(?:able_name\b|extpos\W+\())" \
"capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'Blind SQL Injection Attack. Matched signature <%{TX.0}>',id:'950904',severity:'2'"
Thank you for any help, this problem is holding up an important job. |
|
|||
|
The only thing I've been able to discover so far is that any time mod_security sees a call to user_password in a script, it denies access to it. Unfortunately the script my customer needs to use calls to a file names user_password.js , and mod_security is preventing it from being accessed.
Does anyone know of anything I can do?
|
|
|||
|
Thanks for the reply Darren.
I tried removing little bits and pieces, rules here and there, only to find out that the only way to really get mod_security to grant access to files named user_password.js is to completely remove the entire blocks of SQL Injection protection. I'd have to remove all of this: Code:
# Blind SQL injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "(?:\b(?:(?:s(?:ys\.(?:user_(?:(?:t(?:ab(?:_column|le)|rigger)|object|view)s|c(?:onstraints|atalog))|all_tables|tab)|elect\b.{0,40}\b(?:substring|ascii|user))|m(?:sys(?:(?:queri|ac)e|relationship|column|object)s|ysql.user)|c(?:onstraint_type|harindex)|attnotnull)\b|(?:locate|instr)\W+\()|\@\@spid\b)" \
"capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'Blind SQL Injection Attack. Matched signature <%{TX.0}>',id:'950007',severity:'2'"
SecRule REQUEST_FILENAME|ARGS|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "\b(?:(?:s(?:ys(?:(?:(?:process|tabl)e|filegroup|object)s|c(?:o(?:nstraint|lumn)s|at)|dba|ibm)|ubstr(?:ing)?)|user_(?:(?:(?:constrain|objec)t|tab(?:_column|le)|ind_column|user)s|password|group)|a(?:tt(?:rel|typ)id|ll_objects)|object_(?:(?:nam|typ)e|id)|pg_(?:attribute|class)|column_(?:name|id)|(?:dba|mb)_users|xtype\W+\bchar|rownum)\b|t(?:able_name\b|extpos\W+\())" \
"capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'Blind SQL Injection Attack. Matched signature <%{TX.0}>',id:'950904',severity:'2'"
# SQL injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "(?:\b(?:(?:s(?:elect\b(?:.{1,100}?\b(?:(?:length|count|top)\b.{1,100}?\bfrom|from\b.{1,100}?\bwhere)|.*?\b(?:d(?:ump\b.*\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebtask)|ql_(?:longvarchar|variant))|xp_(?:reg(?:re(?:movemultistring|ad)|delete(?:value|key)|enum(?:value|key)s|addmultistring|write)|e(?:xecresultset|numdsn)|(?:terminat|dirtre)e|availablemedia|loginconfig|cmdshell|filelist|makecab|ntsec)|u(?:nion\b.{1,100}?\bselect|tl_(?:file|http))|group\b.*\bby\b.{1,100}?\bhaving|load\b\W*?\bdata\b.*\binfile|(?:n?varcha|tbcreato)r|autonomous_transaction|open(?:rowset|query)|dbms_java)\b|i(?:n(?:to\b\W*?\b(?:dump|out)file|sert\b\W*?\binto|ner\b\W*?\bjoin)\b|(?:f(?:\b\W*?\(\W*?\bbenchmark|null\b)|snull\b)\W*?\()|(?:having|or|and)\b\s+?(?:\d{1,10}|'[^=]{1,10}')\s*?[=<>]+|(?:print\]\b\W*?\@|root)\@|c(?:ast\b\W*?\(|oalesce\b))|(?:;\W*?\b(?:shutdown|drop)|\@\@version)\b|'(?:s(?:qloledb|a)|msdasql|dbo)')" \
"capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'SQL Injection Attack. Matched signature <%{TX.0}>',id:'950001',severity:'2'"
SecRule REQUEST_FILENAME|ARGS|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "\b(?:user_(?:(?:object|table|user)s|password|group)|a(?:tt(?:rel|typ)id|ll_objects)|object_(?:(?:nam|typ)e|id)|pg_(?:attribute|class)|column_(?:name|id)|substr(?:ing)?|table_name|mb_users|rownum)\b" \
"capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'SQL Injection Attack. Matched signature <%{TX.0}>',id:'950906',severity:'2'"
ugh... |
|
||||
|
Yeap - it's how it happens.
This is why most PHP programmer actually build protection into their own to stop injection attacks either through URL or Form use. Having said that - Joomla STILL after many crys on their forums is still wide open for such attacks. I use a combination of mod_seucirty and suhosin to stop such things - without killing usability all together. I found that mod_security with the default ruleset never stopped all attacks on Joomla site - suhosin was the margin of protection needed to fix it up. Hurray for security. |
|
|||
|
hi
which ruleset of modsecurity (for Apache2.0) do you use pleasE? (where can I download it?) I have some problems with this one for the administrator area( error 404) of joomla 1.5 I use this one: <IfModule mod_security2.c> # # Mod Security2 Rules # Modified September 17, 2007 # base on Kris S. - HostMerit.com's rules # by Tim Schoondergang - TimmiT.nl # mail: Tim.Schoondergang@TimmiT.nl # For use on CPanel servers with Mod_Security2 |
|
||||
|
Quote:
What script/cart is it? Can it be upgraded to solve this or this file be renamed and still work? |
|
|||
|
Quote:
It's a paid cart and I don't know if I should name it here, but I can answer your other two questions since I've sent a lot of related info to their support since I originally encountered this problem, and here is what I've found: - Renaming the file can't be done because the use of it is so heavily encoded into the script. - The developer says they will be providing a fix for this in a future upgrade, but there is no set date / ETA yet. |
|
||||
|
How about setting those particular rules to log and pass then, might be possible to at least keep an eye on it that way. Remarking them out would get you going till the devs work out a fix for the cart of course. If its a paid cart and not publicly accessible you might be ok, short term although I'm not sure I'd want to chance it myself, depending on the situation. (backups might be a good thing to have if you disabled them and get hit.)
BTW, I did find a post on a forum for avactis stating they too are having this problem and would fix for next release. Of course that was posted in March. |
|
||||
|
Mod Security rules can be disabled on a rule-by-rule basis for individual users. You can do it in .htaccess files.
The other option might be to use mod_rewrite to work around the problem named script, although the mod_security solution is probably the correct one. |
|
|||
|
Quote:
- Scott |
|
|||||||
|
Notice that the rules in question in the first post have an ID:
Quote:
Quote:
Now when you find an ID is being hit by a particular account you can remove that ID for that account with: Quote:
Quote:
Then in the modsec.conf file add: Quote:
Quote:
Now include that file: Quote:
|
![]() |
| Thread Tools | |
| Display Modes | |
|
|