> 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]
