2008/1/16, Jeromy Evans [EMAIL PROTECTED]:
a href=javascript:alert('123='+(123));Link A/a
HTML escaped is not equivalent:
a href=javascript:alert('1amp;2gt;3='+(1amp;2gt3));Link B/a
You forgot a semicolon. The correct link is:
a href=javascript:alert('1amp;2gt;3='+(1amp;2gt;3));Link B/a
Antonio Petrelli wrote:
2008/1/16, Jeromy Evans [EMAIL PROTECTED]:
a href=javascript:alert('123='+(123));Link A/a
HTML escaped is not equivalent:
a href=javascript:alert('1amp;2gt;3='+(1amp;2gt3));Link B/a
You forgot a semicolon. The correct link is:
a
2008/1/16, Jeromy Evans [EMAIL PROTECTED]:
You forgot a semicolon. The correct link is:
a href=javascript:alert('1amp;2gt;3='+(1amp;2gt;3));Link B/a
And it *is* equivalent.
Antonio
Ah, my bad. Okay, I'm convinced. :-)
On that basis, the anchor tag just needs ?html added to the
Hi Antonio, as I mentioned in a previous post, it's not so simple as the
href attribute of s:a can legally contain javascript or vbscript.
I think that the problem about a in href attribute is the double
quote character, because it will close the href attribute, then with
a greater than
2008/1/15, Jeromy Evans [EMAIL PROTECTED]:
Hi Antonio, as I mentioned in a previous post, it's not so simple as the
href attribute of s:a can legally contain javascript or vbscript.
This is precisely why the href attribute is not escaped/encoded in the
template. It's deliberate.
Sorry but
2008/1/15, GF [EMAIL PROTECTED]:
On Jan 15, 2008 2:45 PM, Martin Gainty [EMAIL PROTECTED] wrote:
Hi Ganfab
Are you suggesting the href contents disable javascript to disable XSS
script attacks?Martin
No, I think that maybe can be useful to think if doing some checks to
href attribute
On Jan 15, 2008 2:45 PM, Martin Gainty [EMAIL PROTECTED] wrote:
Hi Ganfab
Are you suggesting the href contents disable javascript to disable XSS script
attacks?Martin
No, I think that maybe can be useful to think if doing some checks to
href attribute of s:a is possible to look for double
Hi Ganfab
Are you suggesting the href contents disable javascript to disable XSS script
attacks?Martin __Disclaimer and
confidentiality noteEverything in this e-mail and any attachments relates to
the official business of Sender. This transmission is
2008/1/15, GF [EMAIL PROTECTED]:
Or better, escape them with their corresponding entity.
What do you think about
s:a href=%{myVar} doubleQuoteEncoding=none | urlEncode |
htmlEncode | convertToSingleQuote .../s:a
It could be a solution, but:
a href=javascript:alert(quot;byequot;)Greet/a
It could be a solution, but:
a href=javascript:alert(quot;byequot;)Greet/a
simply works.
Didn't know.
I'm not very into javascript coding :-)
However I think that preventing double quote in some way, can be good.
-
To
Are you suggesting that javascript injection in href be disabled to prevent
XSS attacks?
I'm suggesting that is better that the variable inside s:a
href=%{myVar} should NOT close the generated a because this
would make the browser to execute the eventual javascript
automatically on the page
Are you suggesting that javascript injection in href be disabled to prevent
XSS attacks?
Martin--
- Original Message -
From: GF [EMAIL PROTECTED]
To: Struts Users Mailing List user@struts.apache.org
Sent: Tuesday, January 15, 2008 3:27 AM
Subject: Re: Feedback: WW-2414, XSS attack is
Or better, escape them with their corresponding entity.
What do you think about
s:a href=%{myVar} doubleQuoteEncoding=none | urlEncode |
htmlEncode | convertToSingleQuote .../s:a
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Well,
Or better, escape them with their corresponding entity.
Antonio
Myabe i'm wrong, but:
In XHTML this is wrong:
a href=javascript:window.alert(Example of a link that displays an
alert box);
because i use double quotes inside a javascript, inside a href tag
delimited by double quotes.
GF wrote:
It could be a solution, but:
a href=javascript:alert(quot;byequot;)Greet/a
simply works.
Unfortunately simply HTML Escaping the href attribute isn't
satisfactory. It would corrupt valid javascript.
eg.
a href=javascript:alert('123='+(123));Link A/a
HTML escaped is not
I'm trying to understand where the real problem is.
I think that there are 2 issues. Both important. One in s:url and the
other in s:a
s:url generates a URL that can contain a malicious query string (it
doesn't encode anything except what is passed with s:param). And this
is not good, mainly
It is a bug, since ganfab (sorry I cannot read your name :-) ) tried
I'm Fabio Gandola.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I think that there are two levels of encoding:
1) in s:url, the parameters values must be encoded, to create a valid
(and safe) URL.
2) in s:a, the whole URL must be encoded, simply because it is used
inside an HTML element (a) between double quotes. For example, ''
becomes amp;
So do you
2008/1/14, GF [EMAIL PROTECTED]:
I think that there are 2 issues. Both important. One in s:url and the
other in s:a
s:url generates a URL that can contain a malicious query string (it
doesn't encode anything except what is passed with s:param). And this
is not good, mainly because when
2008/1/12, GF [EMAIL PROTECTED]:
s:url id=xssTest action=test namespace=/test encode=true /
s:a href=%{xssTest}XSS Test/s:a
...
http://localhost:8080/struts2-blank-2.0.11/example/XSS.jsp?
'scriptalert(document.cookie)/script
Fabio, one little question.
I don't see how this code can write the
Fabio, one little question.
I don't see how this code can write the parameter passed to the JSP
page. Probably you pasted the wrong code in the s:url part.
Just add (i.e. in IE6) after the ? the following query string:
'scriptalert('helloworld')/script
2008/1/14, GF [EMAIL PROTECTED]:
Fabio, one little question.
I don't see how this code can write the parameter passed to the JSP
page. Probably you pasted the wrong code in the s:url part.
Just add (i.e. in IE6) after the ? the following query string:
'scriptalert('helloworld')/script
Sorry again Fabio, but I need to understand: the querystring does not seem
to have a param=value structure, and s:url has test as action, and
does not take any dynamic value (i.e. parameter), but maybe I am missing
something.
The bug is calling that page itself (I mean XSS.jsp) passing via
Fabio, I sent a mail to the Struts Developers mailing list about the problem
you reported, please follow the discussion there.
Thanks
Antonio
2008/1/14, Antonio Petrelli [EMAIL PROTECTED]:
2008/1/14, GF [EMAIL PROTECTED]:
Sorry again Fabio, but I need to understand: the querystring
2008/1/14, GF [EMAIL PROTECTED]:
Sorry again Fabio, but I need to understand: the querystring does not
seem
to have a param=value structure, and s:url has test as action, and
does not take any dynamic value (i.e. parameter), but maybe I am missing
something.
The bug is calling that
Antonio Petrelli wrote:
2008/1/14, GF [EMAIL PROTECTED]:
I think that there are 2 issues. Both important. One in s:url and the
other in s:a
s:url generates a URL that can contain a malicious query string (it
doesn't encode anything except what is passed with s:param). And this
is not good,
I don't think this is a critical problem sheerly because the high
prevalence of such vulnerabilities means some of the responsibility
falls on the developer to not trust user-entered data.. The specific
vulnerability is that when includeParams != none, the request URL was
rendered unmodified
Good Morning Jeromy
so for my own edification includeParams != none
which essentially covers HTTP GET and HTTP POST transmissions?
There also seems to be a bug with treatment of URLs in AnchorTag classes
specifically
public class AnchorTagTest extends AbstractUITagTest {
private StringWriter
Is this an IE-only thing?
When I do this w/ FF or Safari I get an encoded parameter and it doesn't
execute the JavaScript :/
URL's mergeRequestParameters method calls UrlHelper's parseQueryString, which
in turn calls Java's URLEncoder.encode; while I haven't spent a lot of time
tracking
2008/1/13, Jeromy Evans [EMAIL PROTECTED]:
I don't think this is a critical problem sheerly because the high
prevalence of such vulnerabilities means some of the responsibility
falls on the developer to not trust user-entered data..
This is not the case: I think it is a bug, since the url in
Thanks for the headsup on AbstractRemoteCallUIBean.java setHref
with encode I only see this implementation for the value assoc'ed with key
(but not URL)
in URLHelper.java buildUrl method calls assuming escapeAmp has been set or
not
where is escapeAmp being set to either true/false?
Thanks/
M--
Antonio Petrelli wrote:
2008/1/13, Jeromy Evans [EMAIL PROTECTED]:
I don't think this is a critical problem sheerly because the high
prevalence of such vulnerabilities means some of the responsibility
falls on the developer to not trust user-entered data..
This is not the case: I
GF wrote:
I think that a good framework is a framework that helps the developer
to not create security issue in his applications.
I agree and Struts2 does that for the most part. Almost every attribute
of every tag in struts2 it HTML escaped. However, the href attribute in
particular
I posted this bug report on the issue tracker:
https://issues.apache.org/struts/browse/WW-2414
In simple words, if you use s:url ... to build an url that is used
with s:a ... the HTML written out will not have the querystring
encoded.. and this lead to very dangerous XSS attacks.
%@ page
2008/1/12, GF [EMAIL PROTECTED]:
http://localhost:8080/struts2-blank-2.0.11/example/XSS.jsp?
'scriptalert(document.cookie)/script
I tested this .jsp inside the 2.0.11 blank application.
I think it's a severe problem, because every Struts2 website using
this way s:url and s:a can be attacked
What browser are you using, and what's the exact query string being used?
I'm having issues duplicating this.
d.
--- Antonio Petrelli [EMAIL PROTECTED] wrote:
2008/1/12, GF [EMAIL PROTECTED]:
http://localhost:8080/struts2-blank-2.0.11/example/XSS.jsp?
'scriptalert(document.cookie)/script
The javascript is executed using Internet Explorer 6 with all of its
patches installed.
The exact query string to do an XSS attack is this
'scriptalert(document.cookie)/script
However I think the problem is not browser related, if you use s:url
and a: as I wrote before, it echoes a non encoded
Of course,
to raise this security issues, the includeParams attribute parameter
of s:url should be different by none
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I don't think this is a critical problem sheerly because the high
prevalence of such vulnerabilities means some of the responsibility
falls on the developer to not trust user-entered data.. The specific
vulnerability is that when includeParams != none, the request URL was
rendered unmodified
39 matches
Mail list logo
