You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by GF <ga...@gmail.com> on 2008/01/12 10:53:37 UTC
Feedback: WW-2414, XSS attack is possible if using and
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">
<title>Insert 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?
>'"><script>alert(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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by GF <ga...@gmail.com>.
> It is a bug, since ganfab (sorry I cannot read your name :-) ) tried
I'm Fabio Gandola.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by Martin Gainty <mg...@hotmail.com>.
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" <ne...@yahoo.com>
To: "Struts Users Mailing List" <us...@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 <an...@gmail.com> wrote:
>
> > 2008/1/13, Jeromy Evans <je...@blueskyminds.com.au>:
> > > 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: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using
and
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Antonio Petrelli wrote:
> 2008/1/13, Jeromy Evans <je...@blueskyminds.com.au>:
>
>> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by Dave Newton <ne...@yahoo.com>.
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 <an...@gmail.com> wrote:
> 2008/1/13, Jeromy Evans <je...@blueskyminds.com.au>:
> > 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by Antonio Petrelli <an...@gmail.com>.
2008/1/13, Jeromy Evans <je...@blueskyminds.com.au>:
> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by Dave Newton <ne...@yahoo.com>.
--- mgainty@hotmail.com wrote:
> There also seems to be a bug with treatment of URLs in AnchorTag classes
> specifically [...]
> tag.setHref("TestAction.action"); // where is this method ?
> [...]
AbstractRemoteCallUIBean.java: public void setHref(String href) {
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by mg...@hotmail.com.
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" <us...@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: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using
and
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
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()%>¶m1=a">link</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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by GF <ga...@gmail.com>.
> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using
and
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by GF <ga...@gmail.com>.
Of course,
to raise this security issues, the includeParams attribute parameter
of <s:url should be different by "none"
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by GF <ga...@gmail.com>.
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
>'"><script>alert(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 <ne...@yahoo.com> wrote:
> What browser are you using, and what's the exact query string being used?
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by Dave Newton <ne...@yahoo.com>.
What browser are you using, and what's the exact query string being used?
I'm having issues duplicating this.
d.
--- Antonio Petrelli <an...@gmail.com> wrote:
> 2008/1/12, GF <ga...@gmail.com>:
> > http://localhost:8080/struts2-blank-2.0.11/example/XSS.jsp?
> > >'"><script>alert(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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by Antonio Petrelli <an...@gmail.com>.
2008/1/12, GF <ga...@gmail.com>:
> http://localhost:8080/struts2-blank-2.0.11/example/XSS.jsp?
> >'"><script>alert(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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by GF <ga...@gmail.com>.
> 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 &
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 copy&paste 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by Antonio Petrelli <an...@gmail.com>.
2008/1/15, Jeromy Evans <je...@blueskyminds.com.au>:
>
> 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 ('<', '>', '&'). I
don't see anything wrong in it.
Antonio
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by Antonio Petrelli <an...@gmail.com>.
2008/1/16, Jeromy Evans <je...@blueskyminds.com.au>:
>
> > You forgot a semicolon. The correct link is:
> > <a href="javascript:alert('1&2>3='+(1&2>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
and
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Antonio Petrelli wrote:
> 2008/1/16, Jeromy Evans <je...@blueskyminds.com.au>:
>
>> <a href="javascript:alert('1&2>3='+(1&2>3));">Link A</a>
>>
>> HTML escaped is not equivalent:
>> <a href="javascript:alert('1&2>3='+(1&2>3));">Link B</a>
>>
>
>
>
> You forgot a semicolon. The correct link is:
> <a href="javascript:alert('1&2>3='+(1&2>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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by Antonio Petrelli <an...@gmail.com>.
2008/1/16, Jeromy Evans <je...@blueskyminds.com.au>:
>
> <a href="javascript:alert('1&2>3='+(1&2>3));">Link A</a>
>
> HTML escaped is not equivalent:
> <a href="javascript:alert('1&2>3='+(1&2>3));">Link B</a>
You forgot a semicolon. The correct link is:
<a href="javascript:alert('1&2>3='+(1&2>3));">Link B</a>
And it *is* equivalent.
Antonio
Re: Feedback: WW-2414, XSS attack is possible if using
and
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
GF wrote:
>> It could be a solution, but:
>> <a href="javascript:alert("bye")">Greet</a>
>> simply works.
>>
Unfortunately simply HTML Escaping the href attribute isn't
satisfactory. It would corrupt valid javascript.
eg.
<a href="javascript:alert('1&2>3='+(1&2>3));">Link A</a>
HTML escaped is not equivalent:
<a href="javascript:alert('1&2>3='+(1&2>3));">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="%{@java.net.URLEncoder@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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by GF <ga...@gmail.com>.
> It could be a solution, but:
> <a href="javascript:alert("bye")">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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by Antonio Petrelli <an...@gmail.com>.
2008/1/15, GF <ga...@gmail.com>:
> >
> > 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("bye")">Greet</a>
simply works.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by GF <ga...@gmail.com>.
>
> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by GF <ga...@gmail.com>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by Antonio Petrelli <an...@gmail.com>.
2008/1/15, GF <ga...@gmail.com>:
>
> On Jan 15, 2008 2:45 PM, Martin Gainty <mg...@hotmail.com> 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 and
Posted by GF <ga...@gmail.com>.
On Jan 15, 2008 2:45 PM, Martin Gainty <mg...@hotmail.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: Feedback: WW-2414, XSS attack is possible if using
and
Posted by Martin Gainty <mg...@hotmail.com>.
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 and
Posted by GF <ga...@gmail.com>.
> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by Martin Gainty <mg...@hotmail.com>.
Are you suggesting that javascript injection in href be disabled to prevent
XSS attacks?
Martin--
----- Original Message -----
From: "GF" <ga...@gmail.com>
To: "Struts Users Mailing List" <us...@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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by GF <ga...@gmail.com>.
> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using
and
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Antonio Petrelli wrote:
> 2008/1/14, GF <ga...@gmail.com>:
>
>> 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 &
>
>
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by Antonio Petrelli <an...@gmail.com>.
2008/1/14, GF <ga...@gmail.com>:
> 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 &
I suppose that, if this encoding is followed this way, the created
URLs can be considered "safe".
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by GF <ga...@gmail.com>.
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 <ga...@gmail.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by Antonio Petrelli <an...@gmail.com>.
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 <an...@gmail.com>:
>
> 2008/1/14, GF <ga...@gmail.com>:
> >
> > >
> > > 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 and
Posted by Antonio Petrelli <an...@gmail.com>.
2008/1/14, GF <ga...@gmail.com>:
>
> >
> > 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 and
Posted by GF <ga...@gmail.com>.
>
> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by Antonio Petrelli <an...@gmail.com>.
2008/1/14, GF <ga...@gmail.com>:
>
> > 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:
>
>'"><script>alert('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 and
Posted by GF <ga...@gmail.com>.
> 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:
>'"><script>alert('helloworld')</script>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Feedback: WW-2414, XSS attack is possible if using and
Posted by Antonio Petrelli <an...@gmail.com>.
2008/1/12, GF <ga...@gmail.com>:
> <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?
> >'"><script>alert(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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org