XSS Bypass double quotes encoding

[Dhiraj Ranka]

Dear All,

While testing one of the application I came across following scenario,

1. Browse a web form

2. Submit it by entering proper values

3. Capture the request in burp

4. Modify one of the parameter for XSS (e.g. "><script>alert(1);</script>)

5. In response it comes as

<input name="search" value="&quot;><script>alert(1)</script>" type="hidden">

I have tried almost all XSS vector, but no luck. It seems that application is just replacing the double quotes with &quot;

Any idea how to bypass this?

--
Be in my web world,
http://dhirajranka.com/
http://twitter.com/dhirajranka/

[abhinav singh]

The error you have listed here is specific to "><script> .
try passing <script>alert(1);</script> and see the response. I am not saying that this string will lead to xss, but it can provide an insight over what filtering mechanism has been applied.

Thanks

--
Get ready for the Dilli Shakedown!
nullcon security conference Delhi Sept 26-29th 2012
http://nullcon.net
 
null - Spreading the right Information
null Mailing list charter: http://null.co.in/section/about/null_list_charter/
 
 

--
Abhinav Singh

Founder - HackingAlert

http://hackingalert.blogspot.com

[Zubin Mithra]

On Mon, Aug 13, 2012 at 6:24 PM, Dhiraj Ranka <dhira...@gmail.com> wrote:

Dear All,

While testing one of the application I came across following scenario,

1. Browse a web form

2. Submit it by entering proper values

3. Capture the request in burp

4. Modify one of the parameter for XSS (e.g. "><script>alert(1);</script>)

5. In response it comes as

<input name="search" value="&quot;><script>alert(1)</script>" type="hidden">

I have tried almost all XSS vector, but no luck. It seems that application is just replacing the double quotes with &quot;

Any idea how to bypass this?

Well, the application is not doing input filtering, its relying of output sanitization of quotes alone. I'd try URL encoding and double URL encoding next.

Cheers,

zm

[Zubin Mithra]

s/of/on 

[Nilesh Kumar]

I would say it's very difficult, as the only way to break the input tag is using " (double quotes) and that itself is being encoded.

--

Get ready for the Dilli Shakedown!
nullcon security conference Delhi Sept 26-29th 2012
http://nullcon.net
 
null - Spreading the right Information
null Mailing list charter: http://null.co.in/section/about/null_list_charter/
 
 

--
Thanks & Regards,
Nilesh Kumar,
Sr.Security Analyst
http://nileshkumar83.blogspot.com
http://linkedin.com/in/nileshkumar83
Mobile- +91-9019076487
                                    Honeywell
Honeywell Technology Solutions Lab

[Dhiraj Ranka]

Zubin, I have tried with URL Encoding but it didn't helped me.

--
Be in my web world,
http://dhirajranka.com/
http://twitter.com/dhirajranka/

[AMol NAik]

I agree with Nilesh Kumar. In order to include <script> tag in example, it's needed to close first "value" like:

<input name="search" value=""><script>alert(1)</script>" type="hidden"> 

Application is doing right thing by encoding.

AMol NAik

[Dhiraj Ranka]

So it means that we cannot break this :(

-- 
Be in my web world,
http://dhirajranka.com/
http://twitter.com/dhirajranka/ 

[skeptic_fx]

Its unbreakable if thats the only context that exists.

But looking at the use case, if there is any other script which access the innerHTML of this value then its exploitable in IE6,7 & 8.

Heres how,

IE treats the Grave Accent (`) as a delimiter like " or ' , whenever IE uses innerHTML to access the  value.

So something like this pretty exploitable.

----------------------------------------

Hi you searched for 

<div id="one">

</div>

<div id="two">

<input value="`` onmouseover=alert(1)"> // XSS inside value attribute which does exactly what you said, encodes only " to &quot;

</div>

<script>

document.getElementById('one').innerHTML=document.getElementById('two').innerHTML;

</script>

-----------------------------

As I said its only context dependent and uses the IE bug and relies heavily on the use of innerHTML later on (Which is a possible scenario in the example you provided)

Other than that it looks unexploit-able to me.

[Gursev]

Dhiraj,

So the developer has done his due diligence and entity encoded the " character. You are out of luck on this one unless you find a vulnerability in the HTML encoding library for the platform. 

Regard,

Gursev

[Ahmed Mohamed]

Dear All,

Sorry for activating this thread, I have the same case but instead of encodeing the double quote , it replaces it with a white space. So does it could be exploitable?

[sandesh anand]

Ahmed - Before we talk about XSS, know that replacing " with space is a bad idea. Not so much from a security perspective, but from a usability/functionality perspective. Imagine user submitting comments with quotes which are magically removed. It would be interesting to know if the replacement happens on the way in (i.e. through a filter) or on the way out (i.e. just before the value is displayed). If it's the latter, then the issue is simpler. If it's the former (I think it is), this is a more serious issue. It could alter the meaning of user input through out the application (especially if user input from free forms are stored in DBs, sent as emails etc). This is one of those cases where developers do "whatever it takes" to fix a security bug and then curse the security guys when the functionality breaks :-). Irrespective of you finding an exploitable XSS, you should make the developer aware of the problems with this approach.

Coming to XSS, the answer is same as the original scenario. Unless you can find another instance in the application/page where user input is reflected (there should be something somewhere.. at least that's the approach I take), XSS is a lost cause. This may not be relevant, but automated tools are much better at finding XSS (or possible locations for exploitation) than humans. So, if you have access to a tool (Burp pro, AppScan etc), I would recommend running your application through it to get some leads. Of course, you will need to take the output of these tools with a grain of (or a "plate full" of) salt and do your due diligence.  

--
_______________________________________________________________________________
nullcon goa V - spread love... not malware...
12-15th Feb 2014
_______________________________________________________________________________

null - Spreading the right Information
null Mailing list charter: http://null.co.in/section/about/null_list_charter/

---
You received this message because you are subscribed to the Google Groups "null" group.
To unsubscribe from this group and stop receiving emails from it, send an email to null-co-in+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.