Catch Suspicious Extensions [January 11, 2009]

[Graycode]

Is it just me or is there odd characters in the filter codes?

[lnminente]

Graycode, yes, we are having problems with the strings inside the code tag. Maybe the solution could be forum would not not wordwrap inside code.

Sidki spoke me about URL-parser and the uExt variable. So to be more general, better use $TST(uExt= instead of $TST(extension= in the code of my above post.

Edited: 090128

[lnminente]

I end my hijack, sorry Kye-U

Place this filter after the URL-Parser, rename it if needed

Code:

[HTTP headers]
In = TRUE
Out = FALSE
Key = "! :I_1 Fixing uFile and uExt from Content-Disposition {ln}090318·"
Match = "$IHDR(Content-Disposition:  attachment;*filename=$AV(\0)*) $TST(\0=(([^.]+.)+)\1([^.]+)\2) $TST(\1=\3.(^?))$SET(uFile=\3)$SET(uExt=\2)"
Replace = "$TST(keyword=*.i_level\:[5].*)$LOG(!C$DTM(c),!I_1 Fixing uFile and uExt from Content-Disposition:  uFile=$GET(uFile)  uExt=$GET(uExt))"

And the suspicious filters can be now resumed to only one filter

Code:

[HTTP headers]
In = TRUE
Out = FALSE
Key = "URL :I-3.3 URL-Killer: Catch Suspicious Extensions {ku,ln}090214 WIP"
URL = "(^$IHDR(Content-Type: *text/(html|javascript)*))"
Match = "$TST(uExt=(hta|e(ml|xe)|hlp|jse|lnk|url|ba(s|t)|c(om|md)|vb(e|s|)|s(cr|hs)|p(if|cd)|a(d(e|      p)|nr)|c(hm|pl|rt)|i(ns|sp)|m(d(b|e)|s(c|i|p|t))|ws(f|h|c)))$LOG(R$DTM(c),I-3.3 Suspicious extension in \h\p)$CONFIRM(SUSPICIOUS FILE EXTENSION FOUND\n\nBlock connection to the URL below?\n\u\n\nFile=$GET(uFile).$GET(uExt)\n)"
Replace = "\k"

[turtle]

(Feb. 12, 2009 12:23 PM)lnminente Wrote:  I end my hijack, sorry Kye-U

Place this filter after the URL-Parser, rename it if needed

Code:

[HTTP headers]
In = TRUE
Out = FALSE
Key = "URL :I-0.1 Fixing uExt and uFile from Content-Disposition {ln}090130"
Match = "$IHDR(Content-Disposition: * filename=\1.(\w)\2 *)$SET(uFile=\1) $SET(uExt=\2) $TST(keyword=*.i_level\:[5].*)$LOG(C$DTM(c),I-0.1 Fixing uExt and uFile from Content-Disposition uFile=$GET(uFile) uExt=$GET(uExt))"

And the suspicious filters can be now resumed to only one filter

Code:

[HTTP headers]
In = TRUE
Out = FALSE
Key = "URL :I-3.3 URL-Killer: Catch Suspicious Extensions {ku,ln}090131 WIP"
URL = "(^$TST(ContentType=*text/(html|javascript)*))"
Match = "$TST(uExt=(hta|e(ml|xe)|hlp|jse|lnk|url|ba(s|t)|c(om|md)|vb(e|s|)|s(cr|hs)|p(if|cd)|a(d(e|      p)|nr)|c(hm|pl|rt)|i(ns|sp)|m(d(b|e)|s(c|i|p|t))|ws(f|h|c)))$LOG(R$DTM(c),I-3.3 Suspicious extension in \h\p)$CONFIRM(SUSPICIOUS FILE EXTENSION FOUND\n\nBlock connection to the URL below?\n\u\n\nFile=$GET(uFile).$GET(uExt)\n)"
Replace = "\k"

lnminente,
Does this filter need to be fixed for the new sidki config file ..................... "! |||||||||||| URL :"
Charlie

[lnminente]

Hi Charlie,
I use my own config, but i suppose these filters can work well with the new sidki. Anyway i prefer Sidki confirm the first filter is able to be incorporated in his config to not cause troubles.

[sidki3003]

There is no "ContentType" global variable in sidki-configs, use $IHDR.
lnminente said the whitespace in "URL :" removes the "URL:" magic, and trouble.

So in this case it should work. It probably doesn't always work. "!-|||||||||||| URL:" header filters expect to be located above any real header matching filter, while "URL :" is located below the "T*" headers.

[lnminente]

Changed to (^$IHDR(Content-Type: *text/(html|javascript)*))"
No ContentType var is now needed (note: change not tested)

(Feb. 14, 2009 05:18 PM)sidki3003 Wrote:  "!-|||||||||||| URL:" header filters expect to be located above any real header matching filter

These filters would be outgoing no?
This is an incomming filter, so it goes after all the outgoing filters

[sidki3003]

Yes, sloppy wording, sorry, rephrasing:

So it should work for posted filters. It probably doesn't work generally, for all filters. "!-|||||||||||| URL:" header filters expect to be located above any real outgoing header matching filter, while "URL :" is located below the outgoing "T*" headers.

[lnminente]

Updated: "Fixing uFile and uExt from Content-Disposition", the old version had buggy codes to determine uFile

Link for testing.

Edit: Heyyy that's my post number four hundred

[arran777]

Bump.

can someone post new code to have these file Extensions added.

js and dll

[TheScaryGuy]

(Jan. 13, 2009 11:44 PM)lnminente Wrote:  Idea!! I think would be great for the framework to write a filter wich sets a variable with the extension of the file we are downloading, it would be very useful for many other filters.
Just waiting some recomends from your experience with this filter to start writing any code

Here is a good link to test your both filters: http://prdownload.berlios.de/avidemux/av..._win32.exe

It works