This morning I surfed beyond my usual feeds to find new and fresh blogs to read and somehow I came across Veracode from Chris Eng. One article rants against the security blogs that sees input validation as a mitigation strategy. Key thing to notice is that I am a developer as well as a security blogger myself, and so forth know what I am talking about. So I want to take this opportunity to make something clear about programming a secure web application.
Chris basically says: ...Can people (that's you, security bloggers) stop saying things like "they should have been filtering inputs?" The most effective way to protect against XSS is HTML entity encoding, NOT input validation... [1] A few things are are good as well as wrong with the above observation. For one it deals with what you are trying to protect against, and so in order not to confuse other people I think an explanation is due. In the case of the Obama website that was vulnerable to XSS, output sanitation would work, but it is only one third of the story. Cross site scripting and SQL injection vectors are close family when it comes down in protecting web applications, since both use characters that makes them possible in the first place. Input validation can be of great importance, but like I said before I rather called it data integrity validation, it is an important step in securing web applications and therefore it cannot be denied. Data integrity validation deals with protection your web applications by utilizing various methods in order to obtain sane data, or data you expected and either treats it or denies it before processing it further, like sending it to a database layer or another script or process that takes the data as input, or output. The first thing to be concerned with is the data that is inputted by either a user or a script. Whether it be manually or an automated tool, because that is the first line of webapplication vulnerability mitigating. This usually involves the following strategy: * data size * data encoding * data type * data preparation These four points are crucial steps in sanitizing supplied data, that I call data integrity checking. Input 1. The most common mistake is not checking the supplied data size. Imagine what happens when I send a 100MB string? this can lead to all sorts of problems, including buffer overflows inside PHP functions. Therefore the first thing you ought to do is to check data length integrity before processing it any further. This can be done by allocating a buffer inside your script, increasing the buffer and counting the string length, then you could either truncate it or raise warnings. 2. Next up can be data encoding. Again, you can raise warnings at this point, or you can set headers, or set the encoding type inside a function for the expected format. Setting a header for let's say UTF-8, or inside a function that checks the string. 3. Data type is very important. In what format is this data supplied? is it integer, string UTF-8, Unicode or lower ASCII like line feeds or nulls? Typecasting is one of the fastest and reliable ways of getting what you expected. If one expect an integer: typecast it to an integer. In C this is normal behavior, but somehow PHP programmers never picked this up. 4. A sub-step here is to check for characters that can harm your applications or database. This involves either encoding the characters, or escaping the characters. That really depends on what data you are processing, but a rule of thumb is to escape dangerous characters. Lastly, concerning SQL denial of service attacks, it is preferred to only process A-Z and 0-9 characters in a search query that utilizes LIKE as search operator, since many characters can be used attack your database and consume a lot of memory, this is mainly very important for SQL server. Now after these sanitation rounds you can safely process the supplied data further. One very important consideration is be cautious with replacing or stripping or truncating data, this usually leads to another loophole and other attacks and is never the preferred method in sanitizing supplied data. Output The next security measure deals with data output integrity. The preferred option to make sure web application cannot break security like XSS is to convert the data to another format instead of verbatim database output that browsers also understand. When data is escaped, you usually want to un-escape it. Then entities play an important role here. But, yet again do not use htmlentities in PHP. Rather use htmlspecialchars in PHP with the ENT_QUOTES and the proper encoding flag for let's say: UTF-8. This implies all data, plus data that can manipulated again when it is outputted to the screen. In strict terms, sanitize the whole header a user sends to you before outputting it. So that basically wraps it up. As you can see, it isn't input or output integrity checking alone. It is both, and differ in different situations. But usually this is how you can program a secure web application considering user-supplied data. It gets a lot harder when users are allowed to define rich markup, like editing style sheets through a web interface. This basically is a lost case to secure properly, because of the innumerable ways in which data can be represented or injected. You could substitute rich user supplied data it with BBcode to let users change a layout, that would be preferred and can produce the same results. In either way, a web application can be made secure. [1] http://www.veracode.com/blog/?p=89 btw, nice blog Chris. :) [Ph4nt0m] <http://www.ph4nt0m.org/> [Ph4nt0m Security Team] <http://blog.ph4nt0m.org/> [EMAIL PROTECTED] Email: [EMAIL PROTECTED] PingMe: <http://cn.pingme.messenger.yahoo.com/webchat/ajax_webchat.php?yid=hanqin_wu hq&sig=9ae1bbb1ae99009d8859e88e899ab2d1c2a17724> === V3ry G00d, V3ry Str0ng === === Ultim4te H4cking === === XPLOITZ ! === === #_# === #If you brave,there is nothing you cannot achieve.# --~--~---------~--~----~------------~-------~--~----~ 要向邮件组发送邮件，请发到 [email protected] 要退订此邮件，请发邮件至 [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
<<inline: image001.gif>>
