views:

90

answers:

2

A lot of companies use CMS software that updates on the regular, often they are security fixes, implying that the previous version have security vulnerabilities. But most clients never upgrade this, or even the CMS has been modified so that an update would break the site. Are there sites that document these exploits, and instruct how to test for them? Or does this information not even get published? (in order not to have people try to exploit them)

Also is there a generic php/js based check list to prevent hack attempts? I know about SQL injections and XSS, but I'm sure that there are more threats out there.

Peace

+1  A: 

The sites which catalog all these vulnerabilities are for example

  • SecurityFocus
  • milW0rm
  • packetstormsecurity

The basic checklist for webapps can be found on OWASP, which is a very general checklist.

http://www.owasp.org/index.php/Top_10_2010-Main

Henri
excellent, milW0rm and packetstormsecurity look very promissing
Moak
+2  A: 

Hello,

SQL Injections and XSS attacks are both solved by parsing all the info that's getting to your code ( addslashes, remove "" tags and so on ); Magic quotes emulation and register_globals off solved the problems from my point of view. Be careful, don't know exactly when, but magic_quotes will be deprecated so don't count on that.

So what other threats are they ? From my experience, the most common human mistakes are related to the authentication. This does not mean that the user does not log in, but it means that an user can read/write info for other users. So, whenever you see a delete link like this : index.php?page=images&action=delete&id=2, try with another id, of another user's image. You should get an error sayings "not your image" or something. This is very very hard to check, so you must count on the developer's experience.

The second biggest problem I had was not related to the code but to the server. FTP passwords got stolen by viruses ( IFrame virus and others ), or the server was hacked using various brute force method.

The conclusion is : if you are sure you checked for SQL Injections and XSS attacks, the last thing you must do is solve the authentication problem ( once again, authentication means that the info you get/alter is YOURS ). People tend to be a little paranoid about the security issues but the most common hacks are not the developer's fault.

Hope this helps;

Best Regards, Gabriel

Gabriel Poama-Neagra
Forgot to mention CSRF, which is very very very popular nowadays. Especially because the solution is not as straightforward as for xss/sqli
Henri