The countless ways of JavaScript :)
Giorgio Maone
Mario Heiderich
Well done - thx! I'll drop a line when fixed...
Greetings,
.mario
Martin Hinks
(splitting up location.hash):
a=0||'ev'+'al',b=0||1[a]('loca' + 'tion.hash'),c=0||'sub'+'str',1[a](b[c](1));
Martin
Giorgio Maone
> Great find - v. impressive - further evilness along the same lines
> (splitting up location.hash):
>
> a=0||'ev'+'al',b=0||1[a]('loca' + 'tion.hash'),c=0||'sub'+'str',1[a](b[c](1));
>
> Martin
Funny, I posted something similar on the http://sla.ckers.org/forum/read.php?2,13209,13314#msg-13314
because when I tried to follow the link from this board the hash-based
vector had been detected.
But apparently it was just a Google Group URL encoding interference
(see the slac.kers link above for working URLs) ;)
.mario
http://demo.php-ids.org/?test=a=0||'ev'+'al',b=0||1[a]('loca'+'tion.hash'),c=0||'sub'+'str',1[a](b[c](1));
I built in a basic converter to detect concatenations and deal with
them - I repeat: It's very basic. So what do you guys think we could
do to solve following problems?:
- various types of concatenation - maybe combined with charcode
- detection of charcode built together by advanced arithmetic
operations including parenthesis and floats
Thx and Greetings,
.mario
On Jul 4, 11:19 pm, Giorgio Maone <giorgio.ma...@gmail.com> wrote:
> On Jul 4, 10:21 pm, "Martin Hinks" <mhi...@gmail.com> wrote:
>
> > Great find - v. impressive - further evilness along the same lines
> > (splitting up location.hash):
>
> > a=0||'ev'+'al',b=0||1[a]('loca' + 'tion.hash'),c=0||'sub'+'str',1[a](b[c](1));
>
> > Martin
>
> Funny, I posted something similar on thehttp://sla.ckers.org/forum/read.php?2,13209,13314#msg-13314
Giorgio Maone
On Jul 5, 12:00 am, ".mario" <Mario.Heider...@googlemail.com> wrote:
> - various types of concatenation - maybe combined with charcode
> - detection of charcode built together by advanced arithmetic
> operations including parenthesis and floats
>
Going down this path you'll end to rewrite a JavaScript
interpreter...
Why don't you just reuse one of the many open sourced out there?
http://www.mozilla.org/projects/tamarin/
http://www.mozilla.org/js/spidermonkey/
http://www.mozilla.org/rhino/
At least, that's how I implemented NoScript "light" filters... a lot
less headaches, and most important, no "enumerating badness"
madness :)
http://www.google.it/search?q=enumerating+badness
SirDarckCat
http://demo.php-ids.org/?test=a%3D0%7C%7C%27ev%27%2B%27al%27%7C%7C0%3Bb%3D0%7C%7C%27locatio%27%3Bb%2B%3D0%7C%7C%27n.h%27%2B%27ash.sub%27%7C%7C0%3Bb%2B%3D0%7C%7C%27str%281%29%27%3Bc%3Db%5Ba%5D%3Bc%28c%28b%29%29#alert(123)
http://demo.php-ids.org/?test=eval.call(this,unescape.call(this,location))#%0d%0aalert%28%22xss%22%29
http://demo.php-ids.org/?test=d%3D0%7C%7C%27une%27%2B%27scape%27%7C%7C0%3Ba%3D0%7C%7C%27ev%27%2B%27al%27%7C%7C0%3Bb%3D0%7C%7C%27locatio%27%3Bb%2B%3D0%7C%7C%27n%27%7C%7C0%3Bc%3Db%5Ba%5D%3Bd%3Dc%28d%29%3Bc%28d%28c%28b%29%29%29#%D%0Aalert%28%22xss%22%29
Greetz!!
On 4 jul, 18:08, Giorgio Maone <giorgio.ma...@gmail.com> wrote:
> On Jul 5, 12:00 am, ".mario" <Mario.Heider...@googlemail.com> wrote:
>
> > - various types of concatenation - maybe combined with charcode
> > - detection of charcode built together by advanced arithmetic
> > operations including parenthesis and floats
>
> http://demo.php-ids.org/?test=a%3D0%7C%7C%27ev%27%2B%27al%27%7C%7C0%3...)
>
> Going down this path you'll end to rewrite a JavaScript
> interpreter...
> Why don't you just reuse one of the many open sourced out there?http://www.mozilla.org/projects/tamarin/http://www.mozilla.org/js/spidermonkey/http://www.mozilla.org/rhino/
Mario Heiderich
Well - I thought about implementing a JavaScript runtime and discussed that with Kishor via chat. But the problem is - if we'd implement that we'd also have to implement one or several SQL sanddboxes to check on the SQL injections, file system stubs to check on the directory traversal and so on. Furthermore we'd loose the basic principle of the application - its light weight.
Also the PHPIDS is all about enumerating badness - and weighting and assessing them. The only chance we have to deliver a value like the impact is to keep a library of possibilities. Of course, the regular expressions need optimizations here and there but I am still the opinion that this is the right way. Imagine the situation we are using a JS interpreter and one vector slips through - we'd need weeks to file the bug to the developers, wait for patches, test ourselves etc. The rules are fixed and committed within hours. Comparable thing with the halfwidth/fullwidth issue and the hardware IDS systems - we were able to detect that input one hour after being posted on sla.ckers/ in the sec news.
Of course we have a kind of arms race at the moment to keep up with your awesome findings but isn't that what it's all about? I've been developing with JS for years and never learned that much about the basic fundamental principles and - let's call them features - of this language. I luv it! I've never seen XSS vectors that advanced like in the last three days when Sir Darck Cat and you appeared in the group and I guess I am not alone with that attitude.
So my proposal is to keep the mentioned principles of the PHPIDS, work out the current issues (has anyone studied math in here?) and keep enhancing the software. Btw - it goes without saying that you guys will be credited in the release notes for the coming release as well as on the contact/credits page of php-ids.org ;)
Also I am planning to write a rather detailed and in depth blog post about advanced filter evasion for gnucitizen.org and I would like to use some of the vectors as examples (the knowledge we gathered here has to be persisted) - you're ok with that?
Greetings and thx,
.mario
--
_______________________
php-ids.org
SirDarckCat
About the php javascript implementation, I made a simple JavaScript
interpreter in PHP (that uses spidermonkey) and makes the following:
function evalJS($code){
$name=md5($code);
$m=@fopen($name,"w");
@fwrite($m,$code);
@fclose($m);
$res=passthru("js $name");
unlink($name);
return $res;
}
This could be an example..
$real_code=evalJS("try{ return new
Function(unescape('".rawurlencode($input_code)."')).toSource(); }
catch(e) { return e.description; }");
That will return the "real code" of the function, and wont execute
it.. the real code I mean, that it will delete useless parenthesis,
useless white spaces, etc.. and that should make easier for checking
with regular expressions.
http://developer.mozilla.org/en/docs/Introduction_to_the_JavaScript_shell
the javascript console doesn't needs to be modified, because it is
pretty safe, you just need to delete the function "load".
There is also a java version: http://www.mozilla.org/rhino/shell.html
Any way, I think that with some work the regular expressions will work
as well, and wont need the client to have access to the passthru
function.
About the:
> Also I am planning to write a rather detailed and in depth blog post about
> advanced filter evasion for gnucitizen.org and I would like to use some of
> the vectors as examples (the knowledge we gathered here has to be persisted)
> - you're ok with that?
Yes of course.
Greetings!!
On 5 jul, 02:55, "Mario Heiderich" <mario.heider...@googlemail.com>
wrote:
> 2007/7/5, SirDarckCat <sirdarck...@gmail.com>:
>
>
>
>
>
> > Recopilation of the sla.ckers.org thread:
>
> >http://demo.php-ids.org/?test=a%3D0%7C%7C%27ev%27%2B%27al%27%7C%7C0%3...)
>
> >http://demo.php-ids.org/?test=eval.call(this,unescape.call(this,locat...
>
> >http://demo.php-ids.org/?test=d%3D0%7C%7C%27une%27%2B%27scape%27%7C%7...
>
> > Greetz!!
>
> > On 4 jul, 18:08, Giorgio Maone <giorgio.ma...@gmail.com> wrote:
> > > On Jul 5, 12:00 am, ".mario" <Mario.Heider...@googlemail.com> wrote:
>
> > > > - various types of concatenation - maybe combined with charcode
> > > > - detection of charcode built together by advanced arithmetic
> > > > operations including parenthesis and floats
>
> > >http://demo.php-ids.org/?test=a%3D0%7C%7C%27ev%27%2B%27al%27%7C%7C0%3...
> > )
>
> > > Going down this path you'll end to rewrite a JavaScript
> > > interpreter...
> > > Why don't you just reuse one of the many open sourced out
> > there?http://www.mozilla.org/projects/tamarin/http://www.mozilla.org/js/spi...
kishord
1) Implementing a JavaScript runtime: This idea may initially sound
really cool, but I am of the opinion that it will not be very useful.
There exist 10 different browsers and we need one for each of them.
Also having a SQL sandbox is an overkill.
Let me first quote my interpretation of the use of sandbox here,
if (thats correct)
{
please continue reading.
}
else
{
please explain what it is -again :)
goto next_reply;
}
Here it goes: "a) After IDS receives an input, we pass the input to
the sandbox and determine if there is a valid JS code in the input. We
also determine if there is any JS at all.
b) Other alternative: Before the response is sent to the client, we
pass it trhough the sandbox, determine the JS that potentially got
added and either block the response or filter the new JS
"
If any of the above statements is true, the important thing to
consider is how an input is mapped to the output?
In case a), input many times is not going to be in valid JS syntax.
E.g. if I am injecting inside a script tag,
the input looks like "; alert(1); which isn't valid JS, JS interpreter
will say there isn't a valid JS code.
In case b), we have no way to know which code was added by an
application and which by attacker. We can't assume that attacker will
always inject alerts and things to exploit/discover XSS. So looking
inside the sandbox for evidence of alert etc. is not appropriate. (I
have concerns with .NETIDS)
There can sometimes be conversions applied by the app on input which
makes it vulnerable. In a hypothetical example if app converts 1 to
'on' and 0 to off, then I can inject 1mouseover and injection
succeeds. We can't do much in these situations.
On math question, I am not good at math but there exist so many
combinations that we will not be able to handle all of them.
n inputs, m encodings, l browsers, alteast 2 languages (J/V S), k
places where input is echoed, p weird things inside browsers.
So conclusion is that even sandbox may not help much. Then why invest
so much into it. And why make PHPIDS heavier.
Really speaking I would like it to remain RegEx based. Thats the way I
love it.
We should cover as many cases with regexes as possible I agree, but if
we can't promise a complete solution using SandBox then why bother
using it.
-Kishor
On Jul 5, 11:06 am, SirDarckCat <sirdarck...@gmail.com> wrote:
> Hi Mario.
>
> About the php javascript implementation, I made a simple JavaScript
> interpreter in PHP (that uses spidermonkey) and makes the following:
>
> function evalJS($code){
> $name=md5($code);
> $m=@fopen($name,"w");
> @fwrite($m,$code);
> @fclose($m);
> $res=passthru("js $name");
> unlink($name);
> return $res;
>
> }
>
> This could be an example..
> $real_code=evalJS("try{ return new
> Function(unescape('".rawurlencode($input_code)."')).toSource(); }
> catch(e) { return e.description; }");
>
> That will return the "real code" of the function, and wont execute
> it.. the real code I mean, that it will delete useless parenthesis,
> useless white spaces, etc.. and that should make easier for checking
> with regular expressions.
>
> http://developer.mozilla.org/en/docs/Introduction_to_the_JavaScript_s...
Martin Hinks
I think a complete runtime is absolute overkill and I think we are
already verging on too much interpretation of the JavaScript. I think
we should focus on detecting ways of executing a payload rather than
getting too hung up on the payload itself. In other words, what we can
detect with regex, we detect, what we cannot we just accept that it is
never going to cath everything without a runtime.
For example: How can any of the JavaScript be used if it is impossible
to inject into a script tag or attribute? If we are catching attempts
to inject the payload in the first place and giving it a high impact
rating then it will be impossible to actually execute the payload
anyway and any other information we can glean about the payload is
merely an impact raiser.
I too have concerns about the implementation of output scanning in
.NETIDS - it is *too* prone to false positives at the moment which is
why, in next weeks release, I am going to remove it by default but
also leave the capability in there as I think it is a useful tool - if
only for debugging purposes to see where there is potential for
fragmented injection. The output scanning works on a much smaller
ruleset than the main scanner but if you have any other suggestions
for how best to deal with this then I would like to hear it.
Martin
SirDarckCat
I understand what you say about the interpretter and the sandbox, I
think you are right, the interpreter may requiere a ot of time.
Martin:
Hi!
well, there is a trend, now to say that XSS is the new BoF, and JS the
new shellcode.
in that case, some IDS, try to detect shellcodes (real shellcodes),
and that's why now exist's a lot of "shellcode encoders", this is
possible in ASM, because the opcodes can be made with printable chars,
but the case of javascript is different, the most filters mario puts,
the harder is to find an attack vector, and even if we dont detect an
approach, if someone does, I dont think it'll stay on the wild for a
long time.. because the affected website will report that the IDS
failed to detect the attack.
Greetings!!
On 5 jul, 08:58, "Martin Hinks" <mhi...@gmail.com> wrote:
> @Kishord: great summary
>
> I think a complete runtime is absolute overkill and I think we are
> already verging on too much interpretation of the JavaScript. I think
> we should focus on detecting ways of executing a payload rather than
> getting too hung up on the payload itself. In other words, what we can
> detect with regex, we detect, what we cannot we just accept that it is
> never going to cath everything without a runtime.
>
> For example: How can any of the JavaScript be used if it is impossible
> to inject into a script tag or attribute? If we are catching attempts
> to inject the payload in the first place and giving it a high impact
> rating then it will be impossible to actually execute the payload
> anyway and any other information we can glean about the payload is
> merely an impact raiser.
>
> I too have concerns about the implementation of output scanning in
> .NETIDS - it is *too* prone to false positives at the moment which is
> why, in next weeks release, I am going to remove it by default but
> also leave the capability in there as I think it is a useful tool - if
> only for debugging purposes to see where there is potential for
> fragmented injection. The output scanning works on a much smaller
> ruleset than the main scanner but if you have any other suggestions
> for how best to deal with this then I would like to hear it.
>
> Martin
>
kishord
I am not a .NET expert, but if .NETIDS can add handlers as getters of
the query parameter elements, maybe it will be a little better.
So essentially you apply output filter not to the response but to the
query elements that are 'echoed'.
something similar to following
<script>
function sanitize(a)
{
if(/<script>/.test(a))
return "";
return a;
}
var $_QUERY = {a: 1, b: 2, a1: 1, b1: 2};
$_QUERY.__defineGetter__("a", function(){return sanitize(this.a1)});
$_QUERY.__defineSetter__("a", function(arg){this.a1=arg});
$_QUERY.a = '<script>';
alert($_QUERY.a);
$_QUERY.a = '< nos cript >';
alert($_QUERY.a);
</script>
Although I am not sure if its possible.
-Kishor
On Jul 5, 3:58 pm, "Martin Hinks" <mhi...@gmail.com> wrote:
> @Kishord: great summary
>
> I think a complete runtime is absolute overkill and I think we are
> already verging on too much interpretation of the JavaScript. I think
> we should focus on detecting ways of executing a payload rather than
> getting too hung up on the payload itself. In other words, what we can
> detect with regex, we detect, what we cannot we just accept that it is
> never going to cath everything without a runtime.
>
> For example: How can any of the JavaScript be used if it is impossible
> to inject into a script tag or attribute? If we are catching attempts
> to inject the payload in the first place and giving it a high impact
> rating then it will be impossible to actually execute the payload
> anyway and any other information we can glean about the payload is
> merely an impact raiser.
>
> I too have concerns about the implementation of output scanning in
> .NETIDS - it is *too* prone to false positives at the moment which is
> why, in next weeks release, I am going to remove it by default but
> also leave the capability in there as I think it is a useful tool - if
> only for debugging purposes to see where there is potential for
> fragmented injection. The output scanning works on a much smaller
> ruleset than the main scanner but if you have any other suggestions
> for how best to deal with this then I would like to hear it.
>
> Martin
>
Martin Hinks
Sadly I'm pretty sure that approach is not possible in .NET - I'd have
to replace the Request object with a new version that implemented all
members whilst overriding the GET and SET methods on each variable.
But what does that actually achieve...? The problem that the Ouput
Scanning is trying to deal with is concaternation of different
querystrings/post parameters without permutation. ie:
?test=<&test2=scri&test3=>
postdata contains test4=pt
If the user echoed out test + test2 + test4 (POST) + test3 the
resulting output is <script>. To concat all of these in every possible
way to look for fragmented injections would be too time consuming
whereas if a user has a page in which they are writing raw data out
and they want it to be output scanned they can compare the results of
a legitimate request (ie. with no malicious input the page scores
impact 10 for example) with a malicious request (if it scores 20 on a
request then the actual impact is 20-10=10).
However, as I said, the problem this is trying to overcome is that
each of those parameters on its own will throw no warning when put
through the IDS - it is only when the user parses them and then writes
them out to a control such as asp:Literal or asp:Hyperlink or even
Page.Title, 3 of the very few controls that do not automatically
encode output in .NET, that the problem exists. So, even if I were to
control access to each querystring - without permuting I have no way
of knowing how the fragmented XSS will be constructed.
You do realise that .NETIDS does all the same filtering as PHPIDS
first on all incoming fields and Output Scanning is just an
experimental bolt-on (at the moment)? Just wanted to make that clear
hehe :p
If anyone is seeing anything I'm not here for detection of fragmented
XSS then I'd really appreciate help - the permutations will just end
up taking too long to compute whereas attaching an Output Filter is
(relatively) trivial in .NET.
@SirDarckCat: Hi!
Been reading your posts but sitting quietly - they are great vectors -
many thanks! In case you didn't realise I'm the culprit(!) for the
.NET version of PHPIDS...
I agree that it is sensible to detect as much as is possible, but I
think this should be within the bounds of Regular Expressions as far
as we can - writing a JavaScript implementation is going to be VERY
labour intensive - it will also have to emulate different browser
behaviours - will undoubtedly be prone to infinite loops, be *slow*
and in general be a nightmare to maintain as opposed to the regexen we
currently employ. Detecting things like a=0||BLAH is a better approach
than attempting to work out via interpretative logic that a=0||'e' +
'v' + 'a' + 'l' is a concatenation of eval. I'm not at any point
arguing against detecting the payload, merely pointing out that to
take this to the nth degree and implement a runtime seems overkill if
there is no method for injecting these highly specific payloads in the
first place.
Hope I made sense here and looking forward to other's feedback on the issues.
Martin
On 7/5/07, kishord <kisho...@gmail.com> wrote:
>
kishord
what I said.
On Jul 5, 6:13 pm, "Martin Hinks" <mhi...@gmail.com> wrote:
> @Kishord:
>
> ...
>
> read more »
.mario
Finally I come to reading your posts and thinking about them - just
fixed the converter class and optimized some rules.
I agree with Martin and Kishor. Yes - a JS engine would be definitely
very cool but too overweighted and question the concept of the PHPIDS.
Also the charcode conversion I meanwhile think is a nice to have in a
basic variant but since it's impossible to cover all different ways to
calculate the charcode together it will always be possible to
circumvent the IDS converters.
Fragmented XSS is definitely an issue very hard to come by - at least
with PHP. I envy .NET a little bit for just being more strict and
structured and having better possibilities to deal with that one. With
PHP there's no real chance to make an application that covers any way
of rendering output and have comparison mechanisms of the should' and
the 'is'. On the other hand fragmented XSS is still found pretty
seldom (or am I wrong?) and it would be another 'nice to have' like
the advanced charcode stuff.
What do you think?
Greetings,
.mario
On Jul 5, 6:13 pm, "Martin Hinks" <mhi...@gmail.com> wrote:
> @Kishord:
>
> ...
>
> read more »
Martin Hinks
makes it *such* hard work!
http://demo.php-ids.org/?test=l=%200%20||%20'str',m=%200%20||%20'sub',x=%200%20||%20'al',y=%200%20||%20'ev',g=%200%20||%20'tion.h',f=%200%20||%20'ash',k=%200%20||%20'loca',d=%20(k)%20%2B%20(g)%20%2B%20(f),a=0%20||%20(y)%20%2B%20(x),b=1[a](d),c=0%20||%20(m)%20%2B%20(l),1[a](b[c](1));#alert(1)
Enjoy!
Martin
Mario Heiderich
Thanx - Awesome one Martin! This one definitely scratches the the sky. "reverse-concatenated hash-contained non-alpha-non-digit-obfuscated XSS" or what should we call that one?
Greetings,
.mario
--
_______________________
php-ids.org
Giorgio Maone
Regarding the JS interpreter VS enumerating badness discussion, it's
worth noticing that I didn't have to adjust NoScript's Anti-XSS
filters to catch any of these "new" vectors.
I know it's a bit unfair because I "live" inside a browser, thus I
don't need extra magic to interface SpiderMonkey, but as I said
following this trend you'll end to rewrite a JS tokenizer using
RegExps (which may even be an interesting project, BTW)
Actually I'm just optimizing NoScript's InjectionChecker for speed and
using the extra wisdom acquired in this thread to *release*
constraints :)
I'm between 0 and 30 millisecs for complex URLs. Have you got any
benchmark for (PHP|NET)IDS?
--
There's a browser safer than Firefox... http://noscript.net
Mario Heiderich
"I know it's a bit unfair because I "live" inside a browser" Yep - and
damn I envy you a little bit ;)
We profile the PHPIDS with xdebug and as far as i can say it doesn't
really hurt according to performance. The major bottlenecks weren't to
find in the matching process it self.
A regex based JS parser is a pretty bizarre idea that the berlios guys
already built - but the project is not more like a PoC in my opinion.
Greetings,
.mario
On 6 Jul., 12:40, Giorgio Maone <giorgio.ma...@gmail.com> wrote:
> http://demo.php-ids.org/?test=_%3Deval%2C__%3Dunescape%2C___%3Ddocume...
Giorgio Maone
wrote:
> A regex based JS parser is a pretty bizarre idea that the berlios guys
> already built - but the project is not more like a PoC in my opinion.
I agree, not mentioning that a dedicated parser is not only "the real
thing" but also probably much more optimized.
On the other hand, maybe you've reached the paranoia limit: why are
you detecting my user agent header?
found injection: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
1.8.1.4) Gecko/20070515 FireFox Firefox/2.0.0.4
rule: (?:\w+\s*.\s*location|document\s*.\s*\w+)|(?:\(\w+[^)]+\))
rule-description: detects javascript location/document property access
impact: 5
Mario Heiderich
paranoid. Fixed too ;)
Greetings,
.mario
Giorgio Maone
christ1an
Awesome work by all of you. I have a lot of catching up to do after the
weekend.
Thank you guys!
Regards,
Christian Matthies
am Samstag, 7. Juli 2007 um 11:43 schrieben Sie:
SirDarckCat
Today I'll introduce the use of XML Predicates in JavaScript to the
vectors.
I was trying to leave this to the end, but..
http://demo.php-ids.org/?test=y%3D%3Ca%3Ealert%3C/a%20%3E%3Bcontent%5By%5D%28123%29
The code:
y=<a>alert</a >;content[y](123)
The XML Predicate:
y=<a>alert</a >;
I'm running out of ideas :P, this filter is a pretty hard obstacle to
any attacker, congratulations mario :D
Greetz!!
PS. btw you dont filter [b]content[/b], content=window
On 7 jul, 05:15, christ1an <ch0...@googlemail.com> wrote:
> Hi,
>
> Awesome work by all of you. I have a lot of catching up to do after the
> weekend.
>
> Thank you guys!
>
> Regards,
> Christian Matthies
>
> am Samstag, 7. Juli 2007 um 11:43 schrieben Sie:
>
> >http://demo.php-ids.org/?test=%24%3Ddocument%2C%24%3D%24.URL%2C%24%24...
Giorgio Maone
feature :(
Have a nice day :)
Giorgio Maone
Look at this:
http://hackademix.net/name.xss/http://demo.php-ids.org/?test=setTimeout//%0D%0A%28name//%0D%0A,0%29///1
Cheers
SirDarckCat
anyway, is it possible to make window.name a function?
window.name=function(){alert(123);}
then, you just need..
name();
anyway I didn't realized that setTimeout is unfiltered..
There are some false positives very interesting..
Copy the title and the first paragraph of:
http://en.wikipedia.org/wiki/Poetry
> Poetry
> From Wikipedia, the free encyclopedia
> Jump to: navigation, search
> For the magazine, see Poetry (magazine).
>
> Poetry (from the Greek "ποίησις", poiesis, a "making" or "creating") is a form of art in which language is used for its aesthetic and evocative qualities in addition to, or in lieu of, its ostensible meaning. Poetry may be written independently, as discrete poems, or may occur in conjunction with other arts, as in poetic drama, hymns or lyrics.
Overall impact: 21
hehe
Greetz!!
On Jul 8, 5:47 pm, Giorgio Maone <giorgio.ma...@gmail.com> wrote:
> @.mario: fast fix, no matter if Holyday :)
>
> Look at this:http://hackademix.net/name.xss/http://demo.php-ids.org/?test=setTimeo...
Mario Heiderich
Wow, that timed out one is beautiful. I fixed the rules btw.
@ SirDarckcat: Yes - I know. Meanwhile there are some patterns which
are detected and are also likely to occur in regular text blocks. On
the other hand it it not recommended to use the PHPIDS on comparable
form elements - them kind should be sanitized with the HTMLPurifier
and done - same is of course for textareas, WYSIWG editors etc.
Greetings and have a nice week!
.mario
Giorgio Maone
> cool xD
> anyway, is it possible to make window.name a function?
>
> window.name=function(){alert(123);}
Unlikely not, all the browsers I tested perform some "special" type
check on that property.
Vector of the day:
Giorgio Maone
s/Unlikely/Unluckily
@.mario: kudos for the quick fix
Here's a slight variation, correctly encoded and hoping to survive
GGroups URL mangling:
Cheers :)
Mario Heiderich
but I am not yet happy with the solution. I guess I will review the filters this evening.
Thx and greetings,
.mario
--
_______________________
php-ids.org