li...@32... wrote:
> on 12/16/05 11:50 AM, Ivan Ristic at iv...@we... wrote:
>
>
>>>Thing that has me stuck is this, everytime I try to punch this string
>>>into a sample "From:" field on a test form, when I print the string to
>>>the screen it comes out exactly like that with the "%0A" and all. The
>>>"%0A" is suppose to be converted into a "\n" which is needed of for the
>>>exploit to work. Problem is that POST data does not get unencoded like
>>>GET data on the other end and the PHP mail() just barfs.
>>>
>>>If I try to send the same string with plain old "\n" then it ends up
>>>looking like this "\\n" on the other side because Magic Quotes is
>>>escaping my backslash.
>>>
>>>I am confused as to how the SPAMMERS have been able to successfully pass
>>>the "\n" which is needed in a POST when I can't do it myself.
>>
>> That's because you are trying to work it out through the browser.
>> But if you access the form programmatically you can construct
>> any content you like, replacing %0A (encoded \n with three characters)
>> with only one character \n.
>>
>>--
>>Ivan Ristic
>
>
>
> Ivan,
>
> What would you recommend as a rule to thwart these attempts?
How about something like (not tested in real life):
SecFilterSelective ARGS_VALUES "\n[[:space:]]*(bcc:|cc:)"
--
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org
|
