Don t Look for Insecure Constructs
Don't Look for Insecure Constructs
A common mistake made by many Web developers is to allow safe HTML constructs for example, allowing a user to send <IMG> or <TABLE> tags to the Web application. Then the user can send HTML tags but nothing else, other than plaintext. Do not do this. A cross-site scripting danger still exists because the attacker can embed script in some of these tags. Here are some examples:
<img src=javascript:alert([code])>
<link rel=stylesheet href="javascript:alert(([code])">
<input type=image src=javascript:alert(([code])>
<bgsound src=javascript:alert(([code])>
<iframe src="/books/1/287/1/html/2/javascript:alert(([code])">
<frameset onload=vbscript:msgbox(([code])></frameset>
<table background="javascript:alert(([code])"></table>
<object type=text/html data="javascript:alert(([code]);"></object>
<body onload="javascript:alert(([code])"></body>
<body background="javascript:alert(([code])"></body>
<p style=left:expression(alert(([code]))>
A list provided to http://online.securityfocus.com/archive/1/272037 goes further:
<a href="javascript#[code]">
<div onmouseover="[code]">
<img src="/books/1/287/1/html/2/javascript:[code]">
<img dynsrc="/books/1/287/1/html/2/javascript:[code]">
<input type="image dynsrc="/books/1/287/1/html/2/javascript:[code]">
<bgsound src="/books/1/287/1/html/2/javascript:[code]">
&<script>[code]</script>
&{[code]};
<img src=&{[code]};>
<link rel="stylesheet href="javascript:[code]">
<iframe src="/books/1/287/1/html/2/vbscript:[code]">
<img src="/books/1/287/1/html/2/mocha:[code]">
<img src="/books/1/287/1/html/2/livescript:[code]">
<a href="about:<script>[code]</script>">
<meta http-equiv="refresh" content="0;url=javascript:[code]">
<body onload="[code]">
<div style="background-image: url(javascript:[code]);">
<div style="behaviour: url([link to code]);">
<div style="binding: url([link to code]);">
<div style="width: expression([code]);">
<style type="text/javascript">[code]</style>
<object class codebase="javascript:[code]">
<style><!--</style><script>[code]//--></script>
<![CDATA[<!--]]><script>[code]//--></script>
<!--: --><script>[code]</script><!--: -->
<<script>[code]</script>
<img src="/books/1/287/1/html/2/blah"onmouseover="[code]">
<img src="/books/1/287/1/html/2/blah>" onmouseover="[code]">
<xml src="/books/1/287/1/html/2/javascript:[code]">
<xml ><a><b><script>[code]</script>;</b></a></xml>
<div datafld="b" dataformatas="html" datasrc="/books/1/287/1/html/2/#X"></div>
[\xC0][\xBC]script>[code][\xC0][\xBC]/script>
Not all browsers support all these constructs. Some are specific to Internet Explorer, Navigator, Mozilla, and Opera, and some are generic. Bear in mind that the two lists are by no means complete. I have no doubt there are other subtle ways to inject script into HTML.
Another mistake I've seen involves converting all input to uppercase to thwart JScript attacks, because JScript is primarily lowercase and case-sensitive. And what if the attacker uses Microsoft Visual Basic Scripting Edition (VBScript), which is case-insensitive, instead? Don't think that stripping single or double quotes will help either many script and HTML constructs take arguments without quotes.
Or how about this: you strip out jscript:, vbscript: and javascript: tags? And as you may have noted from the list above, Netscape Navigator also supports livescript: and mocha: and the somewhat obtuse &{} syntax!
In summary, you should be strict about what is valid user input, and you should make sure the regular expression does not allow HTML in the input, especially if the input might become output for other users. You must do this because you cannot know all potential exploits.
EAN: 2147483647
Pages: 286