Community Creators, Secure Your Code! Part II

by Niklas Bivald

12 Reader Comments

Back to the Article
  1. When you use custom tags you tend to store the result in the database as HTML, so the conversion doesn’t need to take place every time the data is displayed. However, this means you need a function to turn the HTML back into custom tags if the user wishes to edit their data. When a user submits their data, I run the HTML-to-custom function, then htmlentities(), then the custom-to-HTML. This means that the user can use simple HTML in their post and custom tags. The safe HTML will be converted to custom tags before the rest of the HTML is escaped. Jake.
    Copy & paste the code below to embed this comment.
  2. An alternative to storing the content as HTML in the database would be to store the content as your custom code in the database and to generate a static page from it that is served until the content is published again. Yes, this would double the data storage from generating pages dynamically, but it would have the same total storage as a page being cached on your server (which you are probably doing anyway on any site that is either large or has high traffic). It also builds in a natural backup to your data - which is a good thing.
    Copy & paste the code below to embed this comment.
  3. A thought: if you removed all forms of open-parenthesis from any place where code could be executed, would this be enough to nix most Javascript? _’(’ ‘(’ ‘(’ ‘(’ etc._
    Copy & paste the code below to embed this comment.
  4. If your going to chop out all the single and double quotes howz about also looking for ‘fromCharCode’ and killing that as well? Might even put ‘XMLHttpRequest’ and ‘ActiveXObject’ on the black list. You could actually just put all the JavaScript keywords on the black list which are known and limited. Black lists are only a bad idea when the potential threat is unlimited. Given that Javascript is a well know and finite language…? Oh Christopher, I think if you took away the parenthesis you would stop all the url() stuff in CSS which might be desirable. Of course killing all the quotes stops ‘content:’ in CSS as well (but who cares IE doesn’t support it). WHOO!
    Copy & paste the code below to embed this comment.
  5. Well, blacklisting is ok for the known problems, but if you have thousands of user comments and you don’t know yet what bugs the next IE will contain, then a generic approach would be better. I like the idea of just not allowing single and double quotes, since this stops most intrusion approaches and is easy to implement. I just have to find some time…
    Copy & paste the code below to embed this comment.
  6. I have no doubt gained more knowledge into how XSS attacks work and how to protect myself from them in the furute from your series, when I first came accross the article I thought you were referring to patenting your code but was pleased to find your article on the above topics.But I to agree with Andreas blacklisting would be great problem solver as well, and getting a master list is pretty easy my favorite is Jay Allens
    Copy & paste the code below to embed this comment.
  7. I like the simple approaches best, can’t imagine any site owner needing to worry about going deeper. In the past I’ve implemented a more robust solution but it required a recursive regex function which wasn’t too friendly on CPU cycles. I don’t plan on using it again.
    Copy & paste the code below to embed this comment.
  8. If you are target of attacks, I would prefer to secure the community by whitelisting. Especially when you think about future bugs in browsers. When the rules are built the whitelist is easy to administrate.
    Copy & paste the code below to embed this comment.
  9. I think there is nothing more efficient than encoding your pages using one of any encoding software available, such as ionCube PHP encoder. That’s just one of many. I can’t imagine more secure, protective way than this.
    Copy & paste the code below to embed this comment.
  10. Im with Thorsten. I think whitelisting is the best and safest way ever. Nobody needs so much custom tags and if you only allow a few tags, its no problem to handle it.
    Copy & paste the code below to embed this comment.
  11. I would say that whitelisting ist the safest way, too. And it is the easiest way I think. Bye
    Sheela
    Copy & paste the code below to embed this comment.
  12. The more we use javascript/ ajax the more our code becomes buggy. In few years all this ajax hype will die out
    Copy & paste the code below to embed this comment.