-3

There are many methods to protect a website I know, but I was woundering if you can rate how well my methods are in the prevention of SQL-injection and database injection, and most importantly, give me suggestions on other ways to protect my website and database.

What I have in my website: (i) JavaScript + PHP form validation(dual-validation) (ii) sha512 password hashing (iii) mysql_real_escape_string all POST variables going into MySQL queries

How easy/hard are my current methods of prevention to bypass/hack? How can I improve on my current methods or addition of new methods?

shawn a
  • 799
  • 3
  • 13
  • 21
  • [Please](http://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php) do [your](http://stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing-passwords-in-php) [research](http://stackoverflow.com/questions/1996122/how-to-prevent-xss-with-html-php) – PeeHaa Nov 08 '13 at 00:55
  • 1
    "mysql_real_escape_string". I'll stop you right there. `mysql_*` is deprecated. Use PDO / `mysqli_*`. – Ayush Nov 08 '13 at 00:56
  • "How easy/hard are my current methods of prevention to bypass/hack" 30 seconds or less. – Jonast92 Nov 08 '13 at 00:57
  • No finite list of steps will ever assure security. You could be doing this handful of things, but be completely open to attacks in other ways. A finite checklist of security measures will only protect you from whoever made the checklist. In every piece of code you write you need to keep security practices in mind. Always. – David Nov 08 '13 at 01:00

2 Answers2

0

No.

  • You need real hashing (not only sha encryption, but instead you need a hash that consist of encryption, salt and iteration; look at phpass).
  • Use mysqli or pdo (mysq_* is deprecated).
  • mysql_real_escape_string will not defend you from all threats related to what you're trying to protect.
  • You need to use prepared statements.

The list goes on.

Jonast92
  • 4,964
  • 1
  • 18
  • 32
  • hashing != encryption. Also PHP has a native [password hashing API](http://php.net/manual/en/ref.password.php) so there is no need for phpass. – PeeHaa Nov 08 '13 at 00:58
  • I know hashing != encryption. When did I say otherwise? A hash can contain encryption but it's only 1/3 of the picture. Please tell me where I stated otherwise. – Jonast92 Nov 08 '13 at 01:01
  • uhhhm in your answer: "not only sha encryption, but encryption, salt and iteration; look at phpass" – PeeHaa Nov 08 '13 at 01:01
  • I'm talking about a hash that consist of encryption, salting and iteration. – Jonast92 Nov 08 '13 at 01:02
  • Yeah an I'm saying that doesn't make sense becuase there is no encrypting in hashing. None. Nada – PeeHaa Nov 08 '13 at 01:02
  • Why not? I've looked into many algorithms that generate hashes li that, PHPass is one of them. Usually you take a string and a salt, you encrypt it using basic algorithms like md5 or sha*, then you repeat the process numerous times and you have a hashed string. – Jonast92 Nov 08 '13 at 01:03
  • No really you don't. Please read up on the topic of what is encryption and what is hashing. Also please stop using md5 / sha* for password hashing – PeeHaa Nov 08 '13 at 01:04
  • You can decrypt encrypted text, you can't revert hashed string, I've done my homework. I don't use them... You misunderstand entierly what I'm saying. Example reference: http://www.openwall.com/articles/PHP-Users-Passwords – Jonast92 Nov 08 '13 at 01:06
  • You may have done your homework, yet you are suggesting phpass while php has a native password hashing api. – PeeHaa Nov 08 '13 at 01:09
  • Also where does phpass talk about encryption when it comes to hashing passwords? "You can decrypt encrypted text" yeah and you really can't see a problem with that for passwords? – PeeHaa Nov 08 '13 at 01:11
  • And finally if you care you might want to have a look into this: http://blog.ircmaxell.com/2012/10/password-hashing-in-php-talk.html – PeeHaa Nov 08 '13 at 01:13
0

(i) JavaScript + PHP form validation(dual-validation)

Javascript validation is not secure because anyone can use curl or an equivalent tool to fashion their own HTTP requests, bypassing your Javascript validation.

PHP form validation is good to use, but doesn't work for many cases where you can't filter on a predictable pattern. Basically, most string inputs.

(ii) sha512 password hashing

SHA512 has more bits to it than other SHA hashing functions, but more bits doesn't help against dictionary attacks or rainbow tables or brute force attacks.

You don't mention using salting or iterations, which are recommended. Salting is to prevent someone from building a rainbow table in advance. Iterations are to slow down password validation so attackers can't make millions of attempts per second. Check out password hashing function that automatic key stretching, such as Bcrypt or PBKDF2.

(iii) mysql_real_escape_string

As others have commented, the ext/mysql API is deprecated in PHP, and will be removed soon. It's recommended to start writing code with mysqli or PDO now, so you don't have to rewrite all your apps when ext/mysql is removed (or get stuck unable to upgrade to the next version of PHP).

I find it's easier to stay in good habits if one uses prepared queries with parameters instead of escaping. Both methods are effective if you do them consistently, but many developers want to write code speedily, and worrying about calling the right escaping function and then opening and closing the right quotes as you concatenate variables into your query strings slows us down. Once you get used to it, coding with SQL parameters can be very speedy and less error-prone.

There are still other cases of dynamic SQL, for which neither escaping nor query parameters help. Those solutions are only to include literal values in SQL dynamically. But what if I want to choose a column, an expression, or a whole SQL clause dynamically? 

SELECT * FROM MyTable ORDER BY $column_to_sort_by $asc_or_desc

For this, you should be prepared to use whitelisting to allow external inputs to choose dynamic parts, without you having to concatenate external input directly into your SQL. See my presentation SQL Injection Myths and Fallacies for more examples.

Finally, all your methods focus on protecting SQL statements. What about other code injection vectors like eval()? Or other more subtle cases (see the thread Exploitable PHP functions? on StackOverflow)?

What about security vulnerabilities from outputting unencoded HTML (also known as cross-site scripting or XSS)? You can find more information on common vulnerabilities at the OWASP Top 10 Project or the CWE / SANS Top 25 Most Dangerous Software Errors.

Community
  • 1
  • 1
Bill Karwin
  • 538,548
  • 86
  • 673
  • 828