4 ms·

A couple of notes I'd like to mention on this. SANITIZE ALL USER INPUT. ALWAYS. NO EXCEPTIONS. Examples of such user input include GET variables, POST variabl

by onteria 16y ago

A couple of notes I'd like to mention on this. SANITIZE ALL USER INPUT. ALWAYS. NO EXCEPTIONS. Examples of such user input include GET variables, POST variables, cookies, email, web services (yes even your most trusted partner site can be hacked), etc. If you don't have control over it, sanitize it. That means using the appropriate parameter binding functionality of your database / abstraction layer when inserting data. Anything that displays user input text also needs to be sanitized for preventing malicious client side code (XSS). As noted in this article, I recommend having a global include file that all other files can utilize. This lets you define the absolute path to various directories that your application can utilize throughout the code base. If you ever need to switch locations, you only need to change the config variables and not your entire codebase. How to work with databases is often a touchy subject. On one hand you have data abstraction which helps remove many of the deep down logic on how to interact with databases, saving the programmer's time. Indeed, if you switch to another database that is supported by your abstraction layer, it will be easier to migrate. Unfortunately, if you start writing SQL specific to that database, the "easy switch" advantage starts to become null and moot, as you'll have to rewrite much of your SQL anyways. On the other hand you have those who write SQL code specific to the database at hand, making sure to utilize the best performance possible. One thing to also take into consideration is that with data abstraction, you will have to go through the logical branches that the abstraction provides every time you want to work with the database. If you need to do a very large amount of queries constantly, you may start to notice the side effects of this in terms of speed. It's best to take these issues into consideration when designing a database driven application. With regards to localization, I recommend looking at PHP's gettext extension: http://us3.php.net/gettext http://us3.php.net/gettext With this approach, you can provide links or a dropdown to set a session variable, and all strings can be localized to that session variable's value. Obviously you will have to use the gettext functions wherever translatable strings are available, but it's well worth it to make the ease of providing newly translated versions of your site a matter of just doing the translations with minor tweeks here and there.

troels 16y ago
> SANITIZE ALL USER INPUT. ALWAYS. NO EXCEPTIONS. I really don't like that word. Or "filter", "clean" or whatever people call it. It implies that you can somehow run a variable through a filter and scrub of all the evilness. But that is not how to deal with the problem. What need be done, is to encode strings properly when embedding them in a context, that is interpreted in some other context. For example encode entities when inserting into html or urlencode when inserting into a url. Bottom line is - This has nothing to do with user input. It has to do with how you output data.
- onteria 16y ago
  If you're preventing SQL injection, you do need to run the variable through a filter (mysql_real_escape_string, parameter binding, etc.) in order to prevent a successful attack. The other issue is that if I encode entities when inserting html, that means I have to call this on every page view. For simple strings that's not too big a deal, but if I have a lot of content, this gets resource intensive pretty fast for larger scale sites with lots of people hitting a page at once. In this case I'd rather due the encoding once, which handles a majority of cases.
  - prodigal_erik 16y ago
    Encoding is dirt cheap. You probably pay more just for a TCP stack that isn't perfectly tuned for your workload. And you can't pre-encode a string without baking in bad assumptions that you know how it may ever be used. You're going to regret having your data store polluted with HTML-specific encoding as soon as you build an API or integrate a third-party tool (e.g., analytics or sales support), because they will need either raw values or some different encoding than HTML text (SGML entities).

by onteria 16y ago

troels 16y ago

> SANITIZE ALL USER INPUT. ALWAYS. NO EXCEPTIONS. I really don't like that word. Or "filter", "clean" or whatever people call it. It implies that you can somehow run a variable through a filter and scrub of all the evilness. But that is not how to deal with the problem. What need be done, is to encode strings properly when embedding them in a context, that is interpreted in some other context. For example encode entities when inserting into html or urlencode when inserting into a url. Bottom line is - This has nothing to do with user input. It has to do with how you output data.

onteria 16y ago
If you're preventing SQL injection, you do need to run the variable through a filter (mysql_real_escape_string, parameter binding, etc.) in order to prevent a successful attack. The other issue is that if I encode entities when inserting html, that means I have to call this on every page view. For simple strings that's not too big a deal, but if I have a lot of content, this gets resource intensive pretty fast for larger scale sites with lots of people hitting a page at once. In this case I'd rather due the encoding once, which handles a majority of cases.
- prodigal_erik 16y ago
  Encoding is dirt cheap. You probably pay more just for a TCP stack that isn't perfectly tuned for your workload. And you can't pre-encode a string without baking in bad assumptions that you know how it may ever be used. You're going to regret having your data store polluted with HTML-specific encoding as soon as you build an API or integrate a third-party tool (e.g., analytics or sales support), because they will need either raw values or some different encoding than HTML text (SGML entities).