2

I have a very simple app that does allow unauthenticated users to leave comments (maybe later I will incorporate a capatcha). The app then stores the comments in a mysql db. I do my best to filter out special characters but I do not think that is the best approach. What is the best approach to guard against SQL-Injection attacks?

Additionally, the site is heavy in javascript and so I will probably rewrite some of the logic to be server-side. The main vulnerability I see would be a callback function that sends a string to the server. This string is parsed and then submitted to the db. Is this a real vulnerability and if so, how do I fix it? Also, is having logic on the client a risk? What is the criteria there?

Lastly, how do I implement a simple password hash for the db? Do I just follow these instructions? (I ask because I tried and failed but just wanted to make sure I'm chasing the right rabbit)

Also, am I missing anything big?

  • "Also, is having logic on the client a risk?" Huge risk. Never rely on client side filtering (or trust client side input). It's trivial for a malicious user to bypass. – k1DBLITZ Aug 19 '14 at 15:49
  • @k1DBLITZ, I do not have any filtering on client-side just basic tasks mostly related to displaying data. I do have a brief filter but that is just to tell the user if they entered an incorrect character -the actual parsing/filtering happens again serverside. –  Aug 19 '14 at 16:10
  • 1
    Excellent. I think I read too much between the lines and assumed you were using javascript to validate input. – k1DBLITZ Aug 19 '14 at 17:02

1 Answers1

1

For SQL injection, you're basically on the right path. The best advice it to not roll your own. Use something well known; whichever language you're using probably has a library to be used with proper parametrised SQL. OWASP has a very good article including mitigations against this attack vector here

If this string is never executable, then it's not a vulnerability (that I can think of at the moment anyway). Basically, this is an injection vector. If the string is never used directly, then it shouldn't cause an injection vulnerability. If this string is used to control the logic of your application, then yes, this could be vulnerability depending on what it controls and how deep the attackers knowledge of your application is.

For password hashing theory Thomas Pornin has a very good answer here. The gist is to use a known good implementation, and whatever language you are using will likely have a built in method to hash passwords. Just make sure you follow all recommendations in the linked post, such as which algorithm to use and the size of the salt.

As for any other advice, I suggest you check the OWASP Top 10 for excellent advice.

Community
  • 1
Chris Murray
  • 1,275
  • 11
  • 17
  • Awesome, I was thinking along these lines and honestly who really wants to make their own security measures -far better to use existing peer reviewed methods! –  Aug 19 '14 at 15:29