Breaking out of attribute in double quotes

Question

I have a piece of code that allows for

[url]someurl[/url] 

BB-Code and replaces it with

<a href="someurl">someurl</a>

It takes two precautions to prevent XSS.

1. It replaces <, > and " using a simple str_replace.
2. Uses a regex to detect javascript: and data: protocol handlers.

Since browsers decode the attribute value before further interpreting it, you can get around the regex check by encoding the URL using [url]&#x6A ... [/url].

So I get:

<a href="javascript:alert(1)">javascript:alert(1)</a>

Long story short: I want more than a steenkin attribute tage (who would click a link looking like that?!)

Can I somehow encode my ", <, etc. so it won't be replaced by the str_replace but still be interpreted in the context of HTML?

Answer 1

A blacklist approach will always be flawed. For example, under internet explorer you can use the vbscript: URI to execute vbscript code. There are also ways of encoding javascript: to bypass this check. There have been a large number of itunes exploits that rely upon the itunes: URI to exploit itunes from the browser. This is just two examples, but really there could be any URI handler registered on a target system.

I would run this though a htmlencode routine to encode all quote marks and angle brackets. The benefit of this is that the URL could legitimately contain quote marks without being damaged. This is because the browser will automatically perform an html-decode of all attribute values as they are loaded. Then I would enforce that the first 4 characters are http. If the string does not start with http:// or https:// then prepend http://

Answer 2

You can trick someone into clicking on a link like this though:

Javascript: an_open_source_clientside_scripting_language_commonly_implemented_as_part_of_a_web_browser_in_order_to_create_enhanced_user_interfaces_and_dynamic_websites(); function an_open_source_clientside_scripting_language_commonly_implemented_as_part_of_a_web_browser_in_order_to_create_enhanced_user_interfaces_and_dynamic_websites() {alert(1)}

You could try UTF7 encoding evasion but is no longer supported in modern browsers.