2

OWASP Rule 5 Can someone please explain to me exactly what this means and how to implement it in PHP?

Do not encode complete or relative URL's with URL encoding! If untrusted input is meant to be placed into href, src or other URL-based attributes, it should be validated to make sure it does not point to an unexpected protocol, especially Javascript links. URL's should then be encoded based on the context of display like any other piece of data. For example, user driven URL's in HREF links should be attribute encoded.

This answer on SO seems to cover part of it: input is URL, how to protect it from xss with the makeHTMLAttributeSafe($string) function. But how do I check to see if it is an 'unexpected protocol or javascript link? Should I search and replace for certain 'bad' keywords like 'javascript', 'script', 'onload', etc? There is no good reason why any of my users would ever need to enter these terms, so I'm fine with a fairly Draconian approach of removing blacklisted terms if necessary. I've spent a lot of time trying to understand xss, and would really appreciate some clarification on this. Thanks!

Community
  • 1
  • 1
Jeff
  • 191
  • 3
  • 14
  • 1
    CodeIgniter has a very nice xss cleaning method: https://github.com/EllisLab/CodeIgniter/blob/develop/system/core/Security.php - *xss_clean* line 281 – Mike Apr 26 '12 at 16:46
  • Thanks @Mike, that's very helpful. I've never used a PHP framework, but I should really look into it. – Jeff Apr 26 '12 at 17:08
  • CodeIgniter is nice and really well documented. – Mike Apr 26 '12 at 22:11

1 Answers1

0

Whitelist, don't blacklist. There'll always be new protocols (iTunes, for example, uses itms:// for its own purposes) that you're unaware of.

Pick the protocols you want to support in links (probably http://, https://, mailto://, and maybe ftp://) and block any links that start with a different protocol.

ceejayoz
  • 176,543
  • 40
  • 303
  • 368