[Snort-sigs] Question about Content-Disposition, Content-Type, etc. and http_header buffer

Mike Cox mike.cox52 at ...2420...
Tue Oct 16 17:18:04 EDT 2012


I've noticed that in some multipart/form-data POSTs, data that is normally
in the HTTP header gets sent in the body of the message and not parsed by
http-inspect as part of the http_header buffer.  Specifically, the headers
"Content-Type", "Content-Disposition", and "Content-Transfer-Encoding",
although there could be others.  For example:

POST /blackhole/safe.php HTTP/1.1
Host: snort.org
Content-Type: multipart/form-data, boundary=---dG91Y2hteXNub3J0
Content-Length: 8675309

---dG91Y2hteXNub3J0
Content-Disposition: form-data; name="name"

Joshua
---dG91Y2hteXNub3J0
Content-Disposition: form-data; name="play_a_game"

True
---dG91Y2hteXNub3J0
Content-Disposition: form-data; name="file";
filename="GLOBAL_THERMONUCLEAR_WAR.pdf"
Content-Type: application/pdf
Content-Transfer-Encoding: binary
...

So a snort rule looking for a specific filename in a Content-Disposition
header wouldn't match if it were written as you would expect it to be
written.  For example, this wouldn't match the above:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Bad PDF File
Upload"; flow:established,to_server; content:"Content-Disposition";
http_header; content:"filename="; distance:0; http_header; content:".pdf";
distance:0; within:100; http_header; sid:1234567;)

What is the best way to match this and not incur the overhead of using
global content matches?  Is there a plan for the http-inspect pre-processor
to account for this?

Thanks.

-Mike Cox
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20121016/45577735/attachment.html>


More information about the Snort-sigs mailing list