Gary Han - A Nerd Who Tries To Be Cool And Failed Thus Far

    Payment Card Industry Data Security Standard (PCI DSS) and Open Web Application Security Project (OWASP) are big scary words.

    They have a long check list for QA teams to verify that the program is secure and ready for the world.   

    As a programmer, we also need to be aware of these standards, but not memorize them like the IT and QA teams.

    Here I will state a list of things that programmers should be aware of when implementing any kind of features.

    1. (Most Important) Always ALWAYS validate user input! SQL and JavaScript injection can kill you application if a field is not validated.
        Validate your input means to have a validator code that checks each field and make sure that the user is entering what they are suppose to enter.
        i.e. name field should only be letters; interest field should only be numbers.

    2. Do not store sensitive information like password or credit card numbers. If is necessary to store them, store them encrypted in a separate database that is more secure than the general database. (Items and products etc)

    3. encrypt connection with sensitive sessions, i.e. when admin user logs in to view financial reports, check user account balances etc.  It is good to encrypt everything send from server, but is not necessary for performance reasons.

    4. Be prepared for DOS (Denial Of Service) attacks. Usually this is hard to track which requests are legit and which ones are not. But if the application is built and clustered right, it should be able to handle large loads anyway. But most DOS attacks come simultaneously from large number of IPs and making requests in milliseconds.
      There are couple strategies to defend against such attacks,

         -The most common way is to only allow same IP to make request again within a 1-2 second interval to prevent server being spammed from same IP. This solves the single IP spam.
        - Another one to prevent the multi IP spam is to limit the number of unique simultaneous calls all together. Yes, this would result in some users viewing a page timed out or error on their request browser.

              But look at it this way:  If the server we use is able to support 500 people, and 501 people (legit users) logs on and hit the view catalogue button at the same time. There will be a server halt that might not even be recoverable. Therefore, is better we limit the concurrent users to be 500 rather than letting the server freeze.

                  Think of it as a CPU clock, memory clock, is the same idea.

      5. Stack Overflow, in Java each variable is already dynamically allocated. And exceptions will be thrown when overflow happens. For C/C++, we need to make sure we allocate the enough memory for each variable. If not, a hacker could easily store a huge value in a variable to overflow (over writing) the memory address outside the variable scope and change the program behaviour with his own code (the code is stored in that huge value that he input).

    That is about everything a developer should worry about for security. (Please help me add to the list if there are any ones I missed)

    Of course, stupid things like writing users password to a log file, or sending an email with username and password when user requests for a password are also not allowed. But let’s assume we programmers are not that stupid.

    Server securities, and firewall managements, secure password settings, what kind of encryptions to use etc. we will leave those to the IT team.