Using the new rules configuration in UrlScan v3.0 Beta (Part 2)

re: Using the new rules configuration in UrlScan v3.0 Beta (Part 2)

capturetr — Fri, 30 Oct 2009 18:51:57 GMT

thanks good post. i am forward it... <a href = "saglikli-yasam-onerileri.blogspot.com/">Saglikli Yasam</a>

re: Using the new rules configuration in UrlScan v3.0 Beta (Part 2)

Rovastar — Fri, 27 Mar 2009 20:36:29 GMT

For those that are interested here is a guide to use some of the techniques I discussed here for reducing the false positives.

www.iisportal.com/.../advanced-sql-injection-protection-with-urlscan-3x.aspx

re: Using the new rules configuration in UrlScan v3.0 Beta (Part 2)

orjinal lida — Sat, 24 Jan 2009 10:25:21 GMT

thank you

re: Using the new rules configuration in UrlScan v3.0 Beta (Part 2)

oyun oyna — Sun, 18 Jan 2009 16:33:33 GMT

Goodd Jobb!! thanks for this post admin i like it

re: Using the new rules configuration in UrlScan v3.0 Beta (Part 2)

mirc mirç mırc — Fri, 02 Jan 2009 14:36:13 GMT

Aciklama Sohbet Portali Ws

re: Using the new rules configuration in UrlScan v3.0 Beta (Part 2)

mirc mirç mırc — Fri, 02 Jan 2009 14:35:05 GMT

mirc mırc mırç mirc yukle sohbet

re: Using the new rules configuration in UrlScan v3.0 Beta (Part 2)

sohbet — Tue, 02 Dec 2008 18:17:45 GMT

It is interesting blog. Pleasant to me. I wish you a nice day!

Thank you

re: Using the new rules configuration in UrlScan v3.0 Beta (Part 2)

Gazeteler — Thu, 16 Oct 2008 22:10:36 GMT

good article

re: Using the new rules configuration in UrlScan v3.0 Beta (Part 2)

naziml — Tue, 14 Oct 2008 03:36:40 GMT

nustyle -

This is just a sample list. I can't grow this because the more I do, the more false positives I would be introducing for the various applications out there. I expect admins to use this as a starting point and then add and remove from it as need be. HTH.

re: Using the new rules configuration in UrlScan v3.0 Beta (Part 2)

nustyle — Thu, 25 Sep 2008 12:53:17 GMT

hi there,

can you please explain why your list is very short now?

i have a long list now, and i want to cut some from it.

but i dont know what i can cut. can you help me please? where can i find answers :)

Using SPF to Protect Against SQL Injection Worms - Gotham Digital Science

Using SPF to Protect Against SQL Injection Worms - Gotham Digital Science — Tue, 09 Sep 2008 16:49:05 GMT

Pingback from Using SPF to Protect Against SQL Injection Worms - Gotham Digital Science

re: Using the new rules configuration in UrlScan v3.0 Beta (Part 2)

Anonymous — Tue, 29 Jul 2008 05:25:39 GMT

UrlScan does not look at request entity and cannot deal with request.form. Check blogs.iis.net/.../urlscan-v3-0-filtering-based-on-request-entity.aspx

re: Using the new rules configuration in UrlScan v3.0 Beta (Part 2)

Anonymous — Wed, 23 Jul 2008 07:01:21 GMT

Does UrlScan also Filter Request.Form attach?

re: Using the new rules configuration in UrlScan v3.0 Beta (Part 2)

naziml — Thu, 17 Jul 2008 17:53:08 GMT

Rovastar,

I get your point, but here is what I am getting at.

a) UrlRewriter is not a magic bullet either ... however it IS more powerful than UrlScan in its ability to specify complex rules. You can only specify substring matches in UrlScan, but you can do a lot more with UrlRewriter in terms of expressing rules. But I still get your point ... I am coming across as recommending the use of UrlRewriter over UrlScan. This is not my intent ... I believe UrlScan does its job well. There are a few folks who demand a lot of flexibility in their rules ... to them I recommend UrlRewriter. In my opinion the added overhead of maintaining regexs overrules any benefit they provide.

b,c) I can't really argue here :) Regex is complicated and not exactly readable by mere mortals. UrlRewriter module will come with a bunch of UI to make this task easier ... but not foolproof.

d) You would put the capture group in your log file for regex.

All I am saying is that you can't have your cake and eat it too. You can't have a lot of flexibility while still maintaining ease of use. If you are willing to sacrifice the latter for the former, go ahead and use UrlRewriter. Otherwise, stick with UrlScan (I know I do :)).

Hope that clarifies my position.

re: Using the new rules configuration in UrlScan v3.0 Beta (Part 2)

Anonymous — Tue, 15 Jul 2008 18:06:21 GMT

Simply you must know the sql queries running in your app, i. e. I never use any create in my apps runnig for all people, so, I can block create for any sql query (generally it is the used for creating temp tables in a "hand made attack"). With Asprox botnet now, you can be sure than varchar(4000) is a proof af attack and generally there is no a similar clause in any asp/aspx-SQL app. I never use "<" or ">" characters in any sql query in my app, so current automatic setting in URLscan 3.0 is useful against many sql injection attacks, included writing scripts directly to your database. I. e. Declare is generally used only in generated SQL scripts but none in any application, perhaps is more secure creating tables in database and later integrate they with app. You could create an index of used SQL sentences in your internet app and you'll be sure what "keywords" you could block. URLScan is a very good tool, and losing traffic is more related with a missuse than other fact. You can also "normalize" your page naming scheme and your queries scheme to avoid composite characters or spaces and blocking any white space in: be sure than many of attacks will include any %20, included all hexa queries.