People who run websites are generally clueless about securing their websites. What follows is a short list of "seven sins" (I know...a cliché) that are committed by those who operate a website that use a dynamic backend scripting language (PHP, Perl, etc.):
1) Installing third-party components without first reviewing them for how well-written they are, if they have had major security vulnerabilities and/or exploits in the past 12 months, how well defended against automated scripts they are, and how well each component defends itself from known and unknown exploits. If you don't know how to do this, then employ the services of a security expert.
2) Not upgrading components the same day an upgrade becomes publicly available. PHP, MySQL, third-party components, etc. All major releases typically have fixes for security vulnerabilities. And most releases likely already have exploits for those vulnerabilities floating around in the wild. Security firms track both the vulnerability and the exploit and will themselves release the exploit a couple weeks after a fix becomes available (a couple ill-repute firms will release the exploit within 24 hours). Tracking upgrades is easy - use a website monitor program to watch for changes to the site - or sign up for e-mail notifications.
3) Choosing weak passwords for users with access to administrative interfaces (i.e. those with a greater than "generic user" status). A proper administrative password is at least 35 characters in length and completely random with care taken to ensure a crytographically secure random number generator is used (i.e. not based on a PRNG).
4) Writing PHP code without considering the security implications. File manipulation, handling a file upload, assuming that if someone can access a specific portion of code or script that they are allowed to execute it, and cross-site scripting vulnerabilities.
5) Writing code that interacts with MySQL (or other database) without considering the security implications. SQL injection, gaining access to a higher privilege level than allowed, and stealing the data in the database - which is usually critical to the business - if you lost your database data today due to someone stealing it, would you go out of business?
6) Not setting up firewall rules that block ports to anyone but authorized personnel. Blocking access to server resources is critical. If your web host control panel doesn't allow you to restrict access to server resources (e.g. FTP) on an IP address basis (e.g. restrict FTP access to one IP address), then you need to change hosts.
7) Not logging administrative activities somewhere. If something goes horribly wrong, and it can happen to anyone, a log can quickly tell you what the damage is and what needs to happen to fix it. If you don't have a log of all administrative level activities, then you are left to guess. Reinstalling a whole website after a hacker has done their thing can take weeks.
Well, hopefully this will improve the security of some websites and improve a few clueless website operators.
1) Installing third-party components without first reviewing them for how well-written they are, if they have had major security vulnerabilities and/or exploits in the past 12 months, how well defended against automated scripts they are, and how well each component defends itself from known and unknown exploits. If you don't know how to do this, then employ the services of a security expert.
2) Not upgrading components the same day an upgrade becomes publicly available. PHP, MySQL, third-party components, etc. All major releases typically have fixes for security vulnerabilities. And most releases likely already have exploits for those vulnerabilities floating around in the wild. Security firms track both the vulnerability and the exploit and will themselves release the exploit a couple weeks after a fix becomes available (a couple ill-repute firms will release the exploit within 24 hours). Tracking upgrades is easy - use a website monitor program to watch for changes to the site - or sign up for e-mail notifications.
3) Choosing weak passwords for users with access to administrative interfaces (i.e. those with a greater than "generic user" status). A proper administrative password is at least 35 characters in length and completely random with care taken to ensure a crytographically secure random number generator is used (i.e. not based on a PRNG).
4) Writing PHP code without considering the security implications. File manipulation, handling a file upload, assuming that if someone can access a specific portion of code or script that they are allowed to execute it, and cross-site scripting vulnerabilities.
5) Writing code that interacts with MySQL (or other database) without considering the security implications. SQL injection, gaining access to a higher privilege level than allowed, and stealing the data in the database - which is usually critical to the business - if you lost your database data today due to someone stealing it, would you go out of business?
6) Not setting up firewall rules that block ports to anyone but authorized personnel. Blocking access to server resources is critical. If your web host control panel doesn't allow you to restrict access to server resources (e.g. FTP) on an IP address basis (e.g. restrict FTP access to one IP address), then you need to change hosts.
7) Not logging administrative activities somewhere. If something goes horribly wrong, and it can happen to anyone, a log can quickly tell you what the damage is and what needs to happen to fix it. If you don't have a log of all administrative level activities, then you are left to guess. Reinstalling a whole website after a hacker has done their thing can take weeks.
Well, hopefully this will improve the security of some websites and improve a few clueless website operators.
Comments
Post a Comment