Blast! had a little mistyping in the rule - FIXED. Thanks!!

@RSnake,

Is the semicolon vector a cheat sheet candidate? ;)

Web Application Security Journ(ey)al

I think it is - I tried to find it some minutes ago but couldn't.
In IE6/7 it even works combined with backticks:

<code onmouseover= ` ;; document . write(123) ` >abcdefghijk</code>

[edit] and besides semicolon you can also use + and or - [/edit]

Greetings,
.mario



Edited 1 time(s). Last edit at 05/04/2007 04:47AM by .mario.

http://phpids.heideri.ch/?test=%3Ccode%20onmouseover=document.location=/sss/.source%3Eabcdefghijk%3C/code%3E

n1, thx! idea of mine to insist on closing ticks wasn't that good ;)

Greetings,
.mario

http://phpids.heideri.ch/?test=%3Ca%20href=javascript:document.write(123);%3ETest%3C/a%3E

I have posted this requirement ('javascript:') on the group as well.

Thanks,

Web Application Security Journ(ey)al



Edited 1 time(s). Last edit at 05/04/2007 07:29AM by kishord.

FIXED and thanks!

Could you edit page so it also inserts the injection into 3 hyperlinks as a URL, in a BODY, and some other random tag where attribute is single, double and not quoted. That way we can also test against thesese types of attacks:

onload=document.location=/zzz/.source

Seeing not every bit of HTML will be quoted, depending on developer, type of markup being used and using older web applications where quoting was basically excluded when coding.



Edited 1 time(s). Last edit at 05/04/2007 05:37PM by CrYpTiC_MauleR.

@CrYpTiC_MauleR: Good idea - done!

One more thing, what about cases where developers echo input into an inline script.

;document.write(document.cookie);//

can be injected O.O, there are so many places to put bad input =oD yay!

I think someone needs to set up a subversion server so that CrYpTiC_MauleR can check out the source and make his changes/improvements.. :)

--thrill

---

It is not the degrees you hold, but the mind you possess. - thrill

Quote

;document.write(document.cookie);// can be injected O.O, there are so many places to put bad input =oD yay!

Basically correct however pretty much useless for an attacker. If he really wants to gain data or anything, he's going to need more code which is likely to be detected by the IDS. That however does not mean that it's impossible to get through. Therefore, feel free to inject real harmful code. If you succeed, let us know.

Anyway, I'd like to thank you and all others for testing the IDS and helping us to improve the filters. Without this kind of help, we'd be pretty much stuck.

@thrill: We do in fact have a publicly accessable Subversion repository. You can find it on http://phpids.googlecode.com/svn/

Regards,
- http://christ1an.blogspot.com

_______________________
[[url=http://php-ids.org]php-ids.org[/url]] Web Application Security 2.0



Edited 1 time(s). Last edit at 05/04/2007 06:45PM by christ1an.

http://www.securityfocus.com/bid/2118/exploit (yeah I know old exploit but many apps use their own schemes, AIM, Yahoo, Skype etc..)

You should also detect other schemes in case someone is trying to inject an application vulnerability.

\w: should catch them don't know how many false positives it might catch (other than the legit one =oP, unless you put something like (aim|skype|mailto):. If encoded you other regexs will match.

Regarding subversion, its ok I just want to test and gives ideas.



Edited 1 time(s). Last edit at 05/04/2007 08:30PM by CrYpTiC_MauleR.

http://phpids.heideri.ch/?test=%23+onclick%3Ddocument.title%3D%2Fzzz%2F.source
http://phpids.heideri.ch/?test=x%3Ea%3C%2Fa%3E%3Cbody+onload%3Ddocument.title%3D%2Faaa%2F.source+a



Edited 1 time(s). Last edit at 05/04/2007 09:03PM by CrYpTiC_MauleR.

Quote

Basically correct however pretty much useless for an attacker. If he really wants to gain data or anything, he's going to need more code which is likely to be detected by the IDS. That however does not mean that it's impossible to get through. Therefore, feel free to inject real harmful code. If you succeed, let us know.

;document.body.appendChild(document.createElement(/script/.source)).src=/images%/.source+/2Fxss.jpg/.source;//

how about that?

Great stuff, thanks again CrYpTiC_MauleR!

The detection of random or a fix list of URI schemes has to be discussed - guess i will ask the group first before implementing.

I Will update the filter rules on sunday...

Greetings,
.mario

When will you be ready to test for false positives? I've come across a few.

Btw here are more schemes if you decided to add it. http://esw.w3.org/topic/UriSchemes/

Hi!

URI scheme detection and an enhanced version of the event handler detection is now built in - ready for the false positives i would say ;)

Greetings,
.mario

http://www.securityfocus.com/bid/2118/exploit
http://www.securityfocus.com/archive/1/365893
http://www.securityfocus.com/archive/1/399881
http://www.securityfocus.com/bid/8819/exploit

All those URL scheme attacks made it through.

False Positive:
"John Doe" <example@example.com>
His behavior is inexcusable.
My book's binding came undone.
D:\directory\blah.txt

I'm guessing this is not meant to be used on an IT forum because a lot of people post code and false positives will be much higher. So last one above will be ok as long as its not that case.

Hi!

Well - now the rules should be working correctly again - had some serious issues with some PHP settings of mine but now it should work either if magic quotes are on or off. i also optimized the SQLI rule a little bit and removed most of the false positives.

The only one i didn't remove was the John Doe - too much attack pattern in this one ;)

The URI handlers are now detected when combined with an attribute or at least with a "= (or similar) sequence.

Thanks again for all yer testing - feel free to continue! I hope my corrections did'n break formerly working rules but I'll give it a try tomorrow.

Greetings,
.mario

I have wrote down some thoughts concerning the detection of sql injection attacks. Maybe someone has comments on that.

http://groups.google.com/group/php-ids/browse_thread/thread/cc30f2ca52bc50df

Regards,
- http://christ1an.blogspot.com

_______________________
[[url=http://php-ids.org]php-ids.org[/url]] Web Application Security 2.0

I cant view it =o(

Should be public now ;)

Regards,
- http://christ1an.blogspot.com

_______________________
[[url=http://php-ids.org]php-ids.org[/url]] Web Application Security 2.0

I recently added intergration of optional usage of the mb_convert_encoding function (part of the PHP multibyte extension) so there's no way to bypass e.g. UTF7 through the non-UTF7 rules.

Also I will release a testcase with certain utf8/t/base64 mixtures including obfuscated ones the IDS would - i haven't tried yet - stumble at current state (maybe tomorrow - am not sure, high workload @mom).

Any ideas how we could improve the detection of BASE64 payload effectively - at least without blind-converting any incoming parameter from BASE64 to clear text?

Greetings,
.mario

It does not allow <img> but it allow <input type=image>
http://phpids.heideri.ch/?test=%3cinput%20type%3dimage%20SRC=%22jav%09ascript:al%09ert(%26quot;XSS%26quot;);%22

- Hong

@Hong: which browser does that work in? I can't replicate in FF or IE7...

http://www.the-mice.co.uk/switch/ Switch/Twitch
http://code.google.com/p/dotnetids .NETIDS

@Martin - it works in IE6.

- Hong

Excellent find, Hong. Thanks a lot!!

<edit>FIXED</edit>



Edited 1 time(s). Last edit at 05/11/2007 06:18AM by .mario.

It seems that it cannot detect variable width encoding.
http://phpids.heideri.ch/?test=%ff

- Hong