|
My question is, for a "normal" site, what do you think is enough to secure against methods used by "script kiddies"? For example, SQL injection, XSS, and stuff like that. Same question for password hashes. Do you think it is enough to hash with MD5 + random salt, or minimum SHA1 + random salt, or should something even stronger be used? I know that no application is fully secure, but I want to achieve good security without being overly complex. |
||||
|
|
|
This sounds like a "how long is a piece of string" question. There's no definite answer. It all depends on the value of the data or this web site, the likelihood of it being attacked, the skill or tools the attacker would have, the vulnerabilities that the site might already have etc. Also you'd have to weigh the complexity or cost of implementing your security controls compared to how much you gain or lose. e.g. how easy or difficult it is to change the hash from MD5 to SHA1 vs. what might you lose if someone gets those hashes. I would say that the likelihood of any website on the internet to be attacked by script-kiddies is reasonably high. There are plenty of tools, and plenty of bored people who want to have fun, or learn how to be a hacker. So as a minimum, you'd want to make sure you're covered against known vulnerabilities. If you want to go a step further, try to scan it with some tools script kiddies might use yourself to find out. There are also a growing number of SaaS providers offering this kind of service, some of them might even have a basic free option. You can easily start with that, and continue to grow/improve depending on your risk profile. When you consider this, don't just think about script kiddies and hackers. What about your own staff? developers, systems administrators, your hosting provider? People with legitimate access, who might make a mistake, or deliberately do something bad. Those are also a potential risk. Also, it's not just technical issues. Think about social engineering, phishing attacks etc. Other than that, if it's for your own learning and development. Try to list all those security improvements / problems and rate them somehow. Even if you're not sure, it's better to have some priorities in mind. Start with the items that are the biggest 'bang for the buck', i.e. easy to fix, high risk. Then go down the list and gradually improve your security. |
|||||
|
|
Try to understand it from a point of view slightly closer to reality. There are people out there with varying levels of skill who will attack your web system for many reasons spanning from political, commercial, personal beef reasons, or merely for entertainment reasons. The reasons are of no consequence at the end of the day. The fact that a web system is vulnerable and has been exploited is the primary issue. It is the responsibility of the developer to make sure that all inputs are type set, and database calls are prepared correctly. The responsibility of the web application user is to make sure it is up to date with the latest version of the application software, and the latest versions of any plugins and addons they may also use. If application users adhered to this rule then application exploitation would be reduced to a bare shadow of its current self. If you are using an application that has input vulnerabilities that have not been patched by the developers then you can either patch it yourself, or change to an application that is not vulnerable in such manner. If any user however neglects to keep their applications up to date when there are fixes available, then to be blunt, it is they that are the script kiddie not the attacker. |
|||
|
|
