Hi,

I am probing for XSS in an application. Application has a filter which
triggers if I put anything after less than sign '<' except space, %
and >. So application accepts < character but only allows space, % and

will be rejected(no space). I have tested for various encoding also
<%00script is allowed but it puts space between < and script and
browser does not treat it as mark up. I cannot probe for javascript
events as Payloads are reflecting in HTML context not in javascript
context. Any suggestions how can I by-pass this filter.

Have you tried <%73cript and <%53cript, i.e. URL encoding of 's' and 'S'?

Tried various encodings of '<' so you don't trigger the filter at all?

/John

--
My music http://www.johnwilander.com
Twitter https://twitter.com/johnwilander
CV or Résumé http://johnwilander.se

24 maj 2012 kl. 12:16 skrev Appsec User pentestguy.cs@gmail.com:

<%73cript>

--- On Thu, 5/24/12, Appsec User pentestguy.cs@gmail.com wrote:

My first email was half-assed, its early and I needed coffee...

Single encoding will test to see if the filter is applied prior to the value being unencoded or normalized through default behavior of the webserver/framework being used or custom cgi on the target application.

<%73cript>

The example uses URL HEX encoding but I would check other encoding types as well.

Double encoding will test for several conditions: it will test to see if the unencoding or normalization done prior to the filter is recursive, or it will test to see if unencoding or normalization is done after the filter is applied to the value. The second condition is common any time user data crosses multiple environment boundaries, like in SOA environments or if its passed to a data storage layer prior to being accessed and returned to the user.

<%2573cript>

The example uses URL HEX encoding but I would check other encoding types as well, keep in mind you can mix and match the encoding type you use for each iteration they do not need to be the same as you are targeting functionally different portions of the cgi so the behavior could be very different.

An easy tool for doing multiple encoding types on a string is https://hackvertor.co.uk/public

I recommend that if you find yourself doing alot of blackbox testing, generate a set of test strings as well as the match conditions and save them as seperate files to load into the proxy of your choice, similar to fuzzdb. I also recommend you learn and use burp proxy.

Have fun.

D

--- On Thu, 5/24/12, Appsec User pentestguy.cs@gmail.com wrote:

Hi,

I'm no expert, but how about trying %C0%80 ('invalid 2 byte' UTF encoding
for Null)? Does that make any difference?

Br,

m0n

On Thu, May 24, 2012 at 12:16 PM, Appsec User pentestguy.cs@gmail.comwrote:

Hi Monica,

how do you know that %C0%80 will be UTF decoded?
It is fully valid URL-encoding and decodes to  if taken as Unicode.

Probably you mean some obfuscated encodings like:
%C0%BCscript
%C2%BCscript

which are accepted by some web servers (mainly old IIS) which still treat
them as 7-bit US-ASCII ignoring the high bit (to give attackers access ;-)

Cheers,
Achim

Am 30.05.2012 10:23, schrieb Mon:

I believe there are many character representations we could provide as additional examples to test, but ultimately without more data from the individual asking the question we are limited in the amount of insight we can provide.

Filter bypass has a wide spectrum of techniques, many targeting default behavior for specific versions of client-side and server-side software.

I don't believe reciting them all on this thread would be as beneficial as targeted advice based on the observations made by the tester.

My 2 cents.

D

--- On Wed, 5/30/12, Achim Hoffmann websec10@sic-sec.org wrote:

Apologies for late reply, I tried for <<script..filter is
recursive.<%73script and <%53scriptinvokes the filter with 302
response. <%2573 i.e double encoding gives 500 error with the message
that "The request is rejected by HTTP Filter.." This is different from
standard filter behaviour so when I use <%73script filter redirects me
to with 302 message with double encoding it throws 500 error with
above message. Also I notice char-set is not defined in response. I am
testing on IE8, Can I leverage this fact to test XSS. Can some one
point me to place which can help me understand how and in which
schenarios I should test for encoding like, UTF8/7 ASCII unicodeetc, I
am really confused about these, not sure in which specific scenario I
shoudl try these currently I just run burp intruder with every payload
inside it but fails to understand the basic behind few of the
encodings.

On 5/29/12, Daniel Herrera daherrera101@yahoo.com wrote:

Am 18.06.2012 08:57, schrieb Appsec User:

How does the filter define "recursive"? Have you tested with:
<s<cript
<s<script>cript
<script<script
<sc<sc<sc<sc<sc<sc<script>ript>ript>ript>ript>ript>ript>

<%73script and <%53scriptinvokes the filter with 302

Hmm, what is your intention with doubling the s ?

Assuming you tested with  <%2573cript
Then I'd guess that the filter is not in the front-end web server, but
in the application (or the application server).

Up to now I don't see any charset dependencies as everything is plain
7-bit ASCII.
Things may be different if you use UTF-7 like
+ADw-script
+ADwAcwBjAHIAaQBwAHQ-

If you do that in the URL, the web server needs to be stupid enough to
accept and convert UTF-7 there. Otherwise it only makes sense in POSTed
data as there the server has been informed by the preceeding HTTP
header which charset to use.

Hi Achim,

Thanks for your response! Yes I tried for recursive payloads

<s<cript
<s<script>cript
<script<script
<sc<sc<sc<sc<sc<sc<script>ript>ript>ript>ript>ript>ript>

Actually as per my understanding just when filter sees a character
after < it sends 302 redirect except if the character is space or %,
for % it URL decodes and then checks I  guess.

It was not double 's its <%73cript'. My mistake.

How did you confirmed that filtering is happening at application
server layer. So is it like Webserver is url decoding and then
appserver is doing the filtering? Why I am getting different message
with double URL encoding, Is it like Webserver is URL decoding and
Later AppSever is not expecting URL encoded string and hence throwing
500 error message "The request is rejected by HTTP Filter."

I am targeting IIS server and was looking to leverage HPP for XSS but
it adds a comma in between so my script comes back as <,script If I
provide redundand parameter value as < and script.

Is there any other way I can try?

On 6/19/12, Achim Hoffmann websec10@sic-sec.org wrote: