|
From: peter p. <pi...@go...> - 2006-04-22 11:18:12
|
I simply cant figure out whats going on. A single user cannot access a certain webpage on my server (403 by mod_security). All other users (including myself) dont have any problems doing so. The "bad user" can surf the whole page, but as soon as he submits a searchterm he gets a 403. He has no problems with submitting terms at other forms or search at google ;) I couldnt find any rule in the rule-set that correspond with the terms in audit-log. I googled unsuccessful for a similar problem. I dont have any clue how to solve this issue and I dont have any clue what the 'Extension: Security/Remote-Passphrase' - means. I found it a few times at google but it seems not related with mod_security but maybe with my problem? thnx for any hints, ideas and solutions .. thnx peter ==ddfbd861============================== Request: www.adulteducation.at 80.121.27.113 - - [18/Apr/2006:10:29:05 +0200] "POST /de/struktur/suchergebnis//sd/1/ HTTP/1.1" 403 304 "http://www.adultedu cation.at/de/struktur/" "Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC)" VQ8V8D5jlYoAAFjp7WQAAAAF "-" Handler: perl-script ---------------------------------------- POST /de/struktur/suchergebnis//sd/1/ HTTP/1.1 Host: www.adulteducation.at Accept: */* Accept-Language: de Connection: Keep-Alive Referer: http://www.adulteducation.at/de/struktur/ User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC) UA-OS: MacOS UA-CPU: PPC Cookie: __utma=160909933.2016430368.1134477507.1144766388.1145348530.13; __utmz=160909933.1145348530.13.7.utmccn=(referral)|utmcsr=vhs.or.at|utmcct=/96/|ut mcmd=referral; __utmb=160909933; __utmc=160909933 Content-type: multipart/form-data; boundary=---------------------------168071508944249 Extension: Security/Remote-Passphrase Content-length: 597 mod_security-message: Access denied with code 403. Error processing request body: Multipart: invalid boundary encountered: -----------------------------168 071508944249\n [severity "EMERGENCY"] mod_security-action: 403 28 [POST payload not available] HTTP/1.1 403 Forbidden Content-Length: 304 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=iso-8859-1 --ddfbd861-- |
|
From: Ivan R. <iva...@gm...> - 2006-04-22 12:37:33
|
On 4/22/06, peter pilsl <pi...@go...> wrote: > > I simply cant figure out whats going on. A single user cannot access a > certain webpage on my server (403 by mod_security). All other users > (including myself) dont have any problems doing so. The "bad user" can > surf the whole page, but as soon as he submits a searchterm he gets a > 403. The quickest solution for you is to change the encoding used to submit the form. You are using multipart/form-data but this type of encoding is only needed for file uploads. Since you don't need to upload files you can simply remove the encoding information (from the form, the enctype=3D"..." bit) altogether. The form will then default to application/x-www-form-urlencoded and the error will not occur. Read on for the explanation of the error. > I dont have any clue how to solve this issue and I dont have any clue > what the 'Extension: Security/Remote-Passphrase' - means. I found it a > few times at google but it seems not related with mod_security but maybe > with my problem? Probably not. > thnx for any hints, ideas and solutions .. The message you get means ModSecurity believes the request body is invalid. Seing the User-Agent (Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC) I would say this is probably true. ModSecurity 1.9.x does not keep invalid request bodies around so I can't be completely sure, I am guessing the browser is terminating lines with \n where the specifications requires for \r\n. -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall |
|
From: peter p. <pi...@go...> - 2006-04-22 18:42:10
|
Ivan Ristic wrote: > > The quickest solution for you is to change the encoding used to submit > the form. > thnx a lot for your answer. I would prefer a different solution, cause some applications require file-upload and the problem will pop up there again. Unfortunately one of our partners is based on old macs, so I cant avoid/ignore the problem. > > The message you get means ModSecurity believes the request body is > invalid. Seing the User-Agent (Mozilla/4.0 (compatible; MSIE 5.0; > Mac_PowerPC) I would say this is probably true. ModSecurity 1.9.x does > not keep invalid request bodies around so I can't be completely sure, > I am guessing the browser is terminating lines with \n where the > specifications requires for \r\n. > Based on my logs the Problem occurs with **some** MSIE 5.0 and MSIE 5.23 on Power_mac. I've also entries from MSIE 5.23 on Power_Mac where the problem did not occur when submitting the form. Is there a rule where I can disable this check for mod-security? Or a small source-hack that allows further examination of the problem? I dont think that mod_security is completely incompatible with MSIE 5.x on Apple when it comes to multipart-encoding !? thnx, peter > -- > Ivan Ristic, Technical Director > Thinking Stone, http://www.thinkingstone.com > ModSecurity: Open source Web Application Firewall > -- mag. peter pilsl goldfisch.at IT- & dataconsulting tel: +43 650 3574035 tel: +43 1 8900602 fax: +43 1 8900602 15 pi...@go... |
|
From: Thomas A. <tan...@oa...> - 2006-04-22 19:43:39
|
It sounds unreasonable to me to expect mod_security (whether officially or hacked) to modify standards-compatible behavior in order to account for a 5-year out of date browser outputting incorrect information. I do not support anything less than MSIE 5.5 on any of my websites because they do not comply with standards in regards to JavaScript, HTML, etc., and cannot be easily accomodated with graceful failures. If this is only occurring with one customer, why don't you recommend an upgrade to at least MSIE 5.5 if not something more recent. They will also be less prone to security problems and other incompatabilities for their trouble. I doubt even Microsoft supports that version anymore. The browsers continue to be free of charge, so I don't see any downside. Tom On Sat, 2006-04-22 at 20:41 +0200, peter pilsl wrote: > Ivan Ristic wrote: > > > > The quickest solution for you is to change the encoding used to submit > > the form. > > > > thnx a lot for your answer. I would prefer a different solution, cause > some applications require file-upload and the problem will pop up there > again. Unfortunately one of our partners is based on old macs, so I cant > avoid/ignore the problem. > > > > > > The message you get means ModSecurity believes the request body is > > invalid. Seing the User-Agent (Mozilla/4.0 (compatible; MSIE 5.0; > > Mac_PowerPC) I would say this is probably true. ModSecurity 1.9.x does > > not keep invalid request bodies around so I can't be completely sure, > > I am guessing the browser is terminating lines with \n where the > > specifications requires for \r\n. > > > > > Based on my logs the Problem occurs with **some** MSIE 5.0 and MSIE 5.23 > on Power_mac. I've also entries from MSIE 5.23 on Power_Mac where the > problem did not occur when submitting the form. > > Is there a rule where I can disable this check for mod-security? Or a > small source-hack that allows further examination of the problem? > > I dont think that mod_security is completely incompatible with MSIE 5.x > on Apple when it comes to multipart-encoding !? > > > thnx, > peter > > > -- > > Ivan Ristic, Technical Director > > Thinking Stone, http://www.thinkingstone.com > > ModSecurity: Open source Web Application Firewall > > > > |
|
From: Ivan R. <iva...@gm...> - 2006-04-22 20:27:08
|
On 4/22/06, peter pilsl <pi...@go...> wrote: > > Is there a rule where I can disable this check for mod-security? Or a > small source-hack that allows further examination of the problem? No, to both. But you can try to disable request body buffering using something like (untested): SetEnvIfNoCase User-Agent "Mac_PowerPC" \ "MODSEC_NOPOSTBUFFERING=3DSkip request body processing for buggy clients" It's not a trivial issue - multipart parsing is a very sensitive area. That's why I have hesitated to allow for invalid implementations (even with a switch). The consequences of such actions are often difficult to foresee. > I dont think that mod_security is completely incompatible with MSIE 5.x > on Apple when it comes to multipart-encoding !? Could be. I don't have access to check for myself. -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall |
