0
votes

I'm using some software that is blacklisting certain characters "<", ">", "&" for user submitted values.

It isn't HTML encoding the values when displaying the submitted results (outputs all submitted results in a table).

It stores the values in a nvarchar field in Sql Server.

Can you find a XSS vulnerability in this blacklist approach? Looking to see if can get software vendor to HTML encode the output.

EDIT

I've found that the values in the table are first output as javascript variables, and then added to the page. The values in the javascript are javascript encoded. The javascript encoding is doing it's job and escapes values in the string variables.

I'm looking for xss vulnerabilities in the html rendered from this javascript string variable.

Failed Ideas

Given that uses javascript, had a go with javascript unicode representation of < >

"\u003cscript\u003ealert('hi');\u003/script\u003e"

However as mentioned above javascript encoder is doing it's job, and just outputs as text.

1
javascript:alert('Hello World!') will pass this validator. - Oliver
yeah it does, but it doesn't get executed, value is output in a table cell. - Ian
How does the html look? Is the data only put in between tags or also as html attributes. Does the response set a character encoding http header? - Erlend
data is output inside the element <td>Data_Goes_Here</td>, not in the attributes of the element or could do something with onmouseover. Data is output as a javascript varialble, and then from the javascript writen out to the table. - Ian

1 Answers

2
votes

I know this is old, but blacklisting angle brackets does NOT prevent XSS in all cases.

A counter-example is if you put user input into an HTML attribute; e.g. creating a mailto link with their email. If they enter this as their email address:

" onclick="alert('XSS without angle brackets!')"

They have XSS'd your website.