Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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
And it *is* equivalent.
Antonio
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s: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 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 href attribute:
From:
#if parameters.href?if_exists !=
href=${parameters.href}#rt/
/#if
To:
#if parameters.href?if_exists !=
href=${parameters.href?html}#rt/
/#if
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s: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 href
attribute:
Not this fast Jeromy :-)
There are three solutions for this bug:
1) add an extra attribute, for encoding or not encoding the string;
2) encoding in html by default;
3) not encoding at all but document it *very well*.
I opened an issue for this:
https://issues.apache.org/struts/browse/WW-2427
Feel free to add comments there.
Antonio
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 symbol, you will close the a too and finally you can inject any kind of Javascript inside the page. I think that s:a can implement this kind of checking, no? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 I cannot understand: the HTML code, to be valid, needs that every
attribute values that contain special characters ('' '' '') need to be
encoded with the corresponding HTML entity ('lt;', 'gt;', 'amp;'). I
don't see anything wrong in it.
Antonio
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 of s:a is possible to look for double quotes characters that can eventually close the attribute and tag. Or better, escape them with their corresponding entity. Antonio
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 quotes characters that can eventually close the attribute and tag. When someone uses javascript inside the href a the XHTML a it's common to not use double quotes (and use single quotes) because double quotes would close the href attribute. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. Date: Tue, 15 Jan 2008 09:27:03 +0100 Wrom: KVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXF _ Make distant family not so distant with Windows Vista® + Windows Live™. http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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
simply works.
Antonio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s: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 unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 load...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 possible if using s:url ... and s:a ... 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 symbol, you will close the a too and finally you can inject any kind of Javascript inside the page. I think that s:a can implement this kind of checking, no? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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.
it would be ok to do:
a href=javascript:window.alert('Example of a link that displays an
alert box');
So since s:a can be used to generate a good a tag, I think that
can be a nice idea to add some automatic checking and conversion to
prevent exploiting of the generated a.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 equivalent:
a href=javascript:alert('1amp;2gt;3='+(1amp;2gt3));Link B/a
As Martin suggested, you could write code that parses the attribute to
ensure it's not prematurely terminated by a quote. The complication is
that it can't replace double quotes/single quotes with an html
equivalent as it will need to be aware of quote nesting and escaping,
and the tag implementation doesn't know whether the template uses a
single quote or double quote to open the attribute. This problem has
been solved plenty of times before though.
Despite all that, the developer of the tag library did decide to html
escape all the scripting-event attributes already (onclick etc) so maybe
I'm making a pointless point.
More importantly, the developer needs to ensure user-entered data is
escaped, which brings us back to s:url's encode attribute and the use of
variables generally.
Perhaps it would be more useful if could easily escape variables before
inserting them into the HTML:
eg. as per freemarker notation:
s:a href=%{url?html}/s:a
I've used this reliably before
s:a href=%{encode(url)}link/s:a
or
a href=%{encode(url)}link/a
Where encode is a function in the context.
Similarly this will work:
a href=[EMAIL PROTECTED]@encode(url)}link/a
The developer knows best whether a variable can be trusted in the
current context and there are sufficient tools at his disposal to
protect against this particular XSS vulnerability. I agree it may be
useful if s:url encoded the entire query string through.
cheers,
Jeromy Evans
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 because when someone says encode=true, hes expect
to receive a safe URL.
s:a doesn't care about what is putting in the output!
In few words, if in the href of s:a we put a variable %{var} that
contains a double quote and a greater than symbol: , those will
close the a tag.. and malicious javascript can be injected into this
page.
This bad behaviour can happen when we use a URL generated by s:url..
but, and more dangerously, if we put a variable (i.e. coming from the
DB) inside the href of s:a, it can happen that we have a permament
malicious javascript code infecting our site and stealing the cookies
(and sessions...) of our users...
In few words if a hacker found where we put a variable from the DB in
a s:a and he has a way to store in that DB record a malicious code..
the security of every user of our website will be in danger.
Can be acceptable such a thing?
Any thoughts?
GF
On Jan 12, 2008 10:53 AM, GF [EMAIL PROTECTED] wrote:
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.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 think too that s:a behavior should be modified? By the way, I checked the official wiki page at http://struts.apache.org/2.x/docs/a.html If you just copypaste the example at the end of it. And after fixing it from some bugs it has..(about some non matching /s:a and a not valid attribute in s:param. Also that code has the XSS vulnerability. I tested it on the struts2-blank-2.0.11 box. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 someone says encode=true, hes expect to receive a safe URL. 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; I suppose that, if this encoding is followed this way, the created URLs can be considered safe. Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 parameter passed to the JSP
page. Probably you pasted the wrong code in the s:url part.
Ciao
Antonio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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.
Antonio
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 GET the malicious querystring. The test action is never called. You get the XSS exploit on XSS.jsp I pasted somewhere the full code of XSS.jsp, call it passing the malicious querystring (on IE6) and you will see the javascript being executed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 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 GET the malicious querystring. The test action is never called. You get the XSS exploit on XSS.jsp I pasted somewhere the full code of XSS.jsp, call it passing the malicious querystring (on IE6) and you will see the javascript being executed. Ok understood, thanks, sorry for my dumbness :-) It's monday after all :-) Antonio
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 page itself (I mean XSS.jsp) passing via GET the malicious querystring. The test action is never called. You get the XSS exploit on XSS.jsp I pasted somewhere the full code of XSS.jsp, call it passing the malicious querystring (on IE6) and you will see the javascript being executed. Ok understood, thanks, sorry for my dumbness :-) It's monday after all :-) Antonio
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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, mainly because when someone says encode=true, hes expect
to receive a safe URL.
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;
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.
Template from simple theme:
a#rt/
#if parameters.id?if_exists !=
id=${parameters.id?html}#rt/
/#if
#if parameters.href?if_exists !=
href=${parameters.href}#rt/
/#if
...
Id is escaped, href is not. It's the same case for s:submit and s:div's
href attributes. There's no bug in s:a. s:url can be improved however.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 within the HTML because the developer chose to use it in an anchor. I think that a good framework is a framework that helps the developer to not create security issue in his applications. For example, i prefer a framework that offer some features to automatically prevent SQL injection than writing all the checks by my self. A developer will choose the framework that helps him to write code in a fast, clean and safe way. From the wiki: http://struts.apache.org/2.x/docs/url.html This tag is used to create a URL. http://struts.apache.org/2.x/docs/a.html A tag that creates a HTML a . If I read those pages, I will think that I should use those tags to create a a ... pointing to a specific page, but in this case, s:url generates a link doesn't caring about escaping the query string.. and s:a print it in the output without caring that something inside the href value (i.e will close the a tag! I guess the proposal is that if encode=true, the entire URL query section should be URL encoded and not just the additional parameters? Is that right? When I say encode=true, i expect to generate a safe url. And also in s:a, when i place a variable inside the href, I don't expect that the value of that variable is able to close the a tag and place arbitrary javascript after it. I just submitted that issue. I am not so expert about the Struts2 internals and development rules, to say which is the best place to add some code to prevent this XSS attack. Of course I think that is not nice that i say encode=true in s:url and I got a non encoded URL... But apart that problem of s:url encoding, also with s:a it's not nice that the OGNL inside href (that can comes from other places than s:url) is able to close the a tag and add some javascript to the page. Interestingly, encoding may not completely eliminate the vulnerability. In IE6 a href=javascript%3Aalert%28%27hello%27%29 doesn't execute the javascript, but also doesn't issue the request for a page of that name. Please, can you give me a query string that also with encoding can lead to XSS attack? Thank you. PS: i'm sorry if my english is not very good. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 writer = new StringWriter();
private AnchorTag tag;
protected void setUp() throws Exception {
super.setUp();
request.setScheme(http);
request.setServerName(localhost);
request.setServerPort(80);
tag = new AnchorTag();
tag.setPageContext(pageContext);
JspWriter jspWriter = new StrutsMockJspWriter(writer);
pageContext.setJspWriter(jspWriter);
}
public void testActionURL() throws Exception {
tag.setHref(TestAction.action); // where is this method ?
tag.doStartTag();
tag.doEndTag();
assertTrue(writer.toString().indexOf(href=\TestAction.action\)
-1);
assertEquals(a href=\TestAction.action\/a,
writer.toString());
}
where AnchorTag has no setHref method..?
I think I should update JIRA?
Thanks
Martin
- Original Message -
Wrom: AIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZ
To: Struts Users Mailing List user@struts.apache.org
Sent: Sunday, January 13, 2008 12:11 AM
Subject: Re: Feedback: WW-2414, XSS attack is possible if using s:url ...
and s:a ...
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 within the HTML because the developer chose to use
it in an anchor.
I guess the proposal is that if encode=true, the entire URL query
section should be URL encoded and not just the additional parameters? Is
that right?
Interestingly, encoding may not completely eliminate the vulnerability.
In IE6 a href=javascript%3Aalert%28%27hello%27%29 doesn't execute
the javascript, but also doesn't issue the request for a page of that
name.
GF wrote:
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 execution I guess I thought this was the path taken for any GET parameters. d. --- Antonio Petrelli [EMAIL PROTECTED] 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 think it is a bug, since the url in s:url should be *parsed* before, extracting the eventual querystring and its parameters. It is a bug, since ganfab (sorry I cannot read your name :-) ) tried to use the s:param and it works. I don't know how c:url of JSTL works, but I firmly suppose that it parses the URL. Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 s:url should be *parsed* before, extracting the eventual querystring and its parameters. It is a bug, since ganfab (sorry I cannot read your name :-) ) tried to use the s:param and it works. I don't know how c:url of JSTL works, but I firmly suppose that it parses the URL. Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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-- - Original Message - From: Dave Newton [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Sunday, January 13, 2008 10:50 AM Subject: Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ... 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 execution I guess I thought this was the path taken for any GET parameters. d. --- Antonio Petrelli [EMAIL PROTECTED] 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 think it is a bug, since the url in s:url should be *parsed* before, extracting the eventual querystring and its parameters. It is a bug, since ganfab (sorry I cannot read your name :-) ) tried to use the s:param and it works. I don't know how c:url of JSTL works, but I firmly suppose that it parses the URL. Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 think it is a bug, since the url in s:url should be *parsed* before, extracting the eventual querystring and its parameters. Yes, I agree it's an issue. I just don't think it's a critical vulnerability. Dave Newton wrote: 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 :/ Yes, it's specific to IE in that IE doesn't URLEncode all invalid URLs. However, it broadly applies to any user agent that allows an illegal URL to be submitted (which is what someone would use if trying to when trying out such an exploit). 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 execution I guess I thought this was the path taken for any GET parameters. I agree. I haven't dug into the code any further, but I think the specific issue is that s:url URLEncodes the supplied parameters (as you'd expected) but the base URL may already contain unencoded characters. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 can't (easily) be automatically HTML Escaped or URL encoded
as it's valid for this attribute to contain blocks of javascript or
vbscript. This applies to s:a, s:div, s:submit and possibly other
tags. The developer needs to design-out such vulnerabilities as they
would with any html tag at the source of the data.
When you use s:url with includeParams != none and place the result in an
href, you're doing the equivalent of :
a href=%=request.requestURI()%param1=alink/a
When you set encode=true, I believe this is roughly equivalent to
(excluding the logic around the ? and ):
a
href=%=request.requestURI()+''+URLEncoder.encode('param1')+'='+URLEncoder.encode('a')%link/a
The specific issue here is that the requestURI may already contains
unencoded characters, so perhaps the s:url tag should URLEncode the
entire EXISTING query string instead of just its additional parameters.
My main point though was that it's not a critical issue, it's just an issue.
Interestingly, encoding may not completely eliminate the vulnerability.
In IE6 a href=javascript%3Aalert%28%27hello%27%29 doesn't execute
the javascript, but also doesn't issue the request for a page of that name.
Please, can you give me a query string that also with encoding can
lead to XSS attack?
Thank you.
No, nothing leaps to my mind, but in the example above IE doesn't behave
normally and that's a good starting point for potential exploits. If
someone was clever enough to exploit that IE used to interpret
scr\nipt as valid html (a line break in the middle of a tag name) they
certainly would have investigated if there's any cases where, for
example, javascript%3a is interpreted as javascript:.
PS: i'm sorry if my english is not very good.
Your English is excellent!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 language=java contentType=text/html; charset=ISO-8859-1
pageEncoding=ISO-8859-1%
%@ taglib prefix=s uri=/struts-tags%
!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html
head
meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1
titleInsert title here/title
/head
body
s:url id=xssTest action=test namespace=/test encode=true /
s:a href=%{xssTest}XSS Test/s:a
/body
/html
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 with XSS.
Please give some feedback.
Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 with XSS. It looks like a critical bug (security exploit): the URL should be parsed, separating the query string into parameters. Thoughts? Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 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 with XSS. It looks like a critical bug (security exploit): the URL should be parsed, separating the query string into parameters. Thoughts? Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 URI.. and in this way you can place malicious javascript inside the page. (watch the resulting HTML..) On Jan 12, 2008 6:05 PM, Dave Newton [EMAIL PROTECTED] wrote: What browser are you using, and what's the exact query string being used? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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]
Re: Feedback: WW-2414, XSS attack is possible if using s:url ... and s:a ...
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 within the HTML because the developer chose to use it in an anchor. I guess the proposal is that if encode=true, the entire URL query section should be URL encoded and not just the additional parameters? Is that right? Interestingly, encoding may not completely eliminate the vulnerability. In IE6 a href=javascript%3Aalert%28%27hello%27%29 doesn't execute the javascript, but also doesn't issue the request for a page of that name. GF wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
