Prevention of attack to a website

Question

When i need to upload a database to a hosting provider with a php based website, the only things i need to care about is :

1) SQL injection, i can skip this using magic_quotes and if magic quotes is not on, i add addslashes. 2)prevent user to upload malicious file to my website by setting a control, Both on which file extension (example just .jpg or jpeg) and which file type (image/jpg ecc).

Now it's just these the 2 main things i need to worry?

And: if i just make the administrator of the website be able to upload image or insert new article in database after he enter a password, i need to prevent that 2 kind of attack? Or that area is safe after i encode my password with md5 on database?

Last: if i encode my password in MD5, when the user enter the password i need to encode it Before sending it with method POST?

EDIT:

For whoever downvote my question, the 2 attack i posted was just an example, so my question was wider, like, what i need to be informed on if i want to prevent attack to my website. Just to have something and go to look for it. In fact MOST tutorial on the net, specially in my native Language are outdated or bad.

`SQL injection, i can skip this using magic_quotes and if magic quotes is not on, i add addslashes.` You're not really starting on the right foot. And forget MD5, use a stronger method — Damien Pirsy, Mar 07 '14 at 16:24
_Every_ single line of your question is wrong. You need to learn a lot more before you can write secure code. — SLaks, Mar 07 '14 at 16:25
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project — SLaks, Mar 07 '14 at 16:25
http://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php?rq=1 Come on, is right on the side bar. — Mihai, Mar 07 '14 at 16:25
Look at `PDO` or `mySQLi` to learn `prepared statements` for some better) security. And `MD5` for passwords? Ouch... — Albzi, Mar 07 '14 at 16:26
Caution the **iFrame Hijacking** http://seclab.stanford.edu/websec/frames/ even facebook got that kind of attack — jean, Mar 07 '14 at 16:27
As SLaks said.... every single one of your assumptions is wrong. It's as if you took best practice security and did the opposite of everything. You need to take each point case-by-case and understand what is going on if you expect to make something remotely secure. Do some hacks yourself against your own code, and see how easy it is. — Brad, Mar 07 '14 at 16:27
@Mihai i saw that, but my question was really more general, i am not asking just about sql injection, but to prevent attack. — user3384514, Mar 07 '14 at 16:28
Most hash passwords algorithms don't protect you from **Rainbow Tables** http://en.wikipedia.org/wiki/Rainbow_table — jean, Mar 07 '14 at 16:29
Usually, TLS is considered the preferred method of protecting data between client and server. If you're not doing `https://` for passwords, you're in a world of hurt. SHA1 (or in the past MD5) could be used to store a salted hash in the DB for later... I guess you could do the hash on the client, but that probably isn't typical (for one thing client likely won't know salt). @jean That's what salt is for... — , Mar 07 '14 at 16:30
*au contraire* @ebyrob that's what rainbow tables are for (defeat salted hash) the problem with hash they are very fast to calculate since they are intended to hash entire files and ended used to hash small strings. The only way to avoid RT now is using a "slow" hash — jean, Mar 07 '14 at 16:33
You've got so much misinformation in this question that it's worrying to an extreme. A guide like [PHP The Right Way](http://www.phptherightway.com/) outlines the recommended best practices and is an **essential read**. The information you're basing your opinions on is **at least** fifteen years out of date. — tadman, Mar 07 '14 at 16:33
@jean How are you going to precompute all possible hash results for a 2048-bit salt field? Where are you going to store them? Note: I'm talking about unique (hopefully secure-random, per-user salt. along with a "server unique") Even if you only tabled "123456" and "password" it wouldn't work. — , Mar 07 '14 at 16:35
@tadman i am asking this, becase i still find a lot of tutorial that use that information, and since the argument is wide, i post here to have a grasp of what take for true or not. And to have a list of problem to analyze — user3384514, Mar 07 '14 at 16:36
@ebyrob in a cloud of course, and let's guess the storage capacity of those things in the next years. But no fear, there's already very slow hash algorithms (just cannot remember it's name now) — jean, Mar 07 '14 at 16:38
@user3384514 It's great you're asking questions, but the sorts of questions you're asking suggest you're using really awful references. Instead of trying to build an application from an empty directory, the best way to do this now is to pick a [development framework](http://codegeekz.com/best-php-frameworks-for-developers/) that suits your style and needs. That will provide a lot of tested, high-quality examples to work from and you can leverage a huge amount of community code. — tadman, Mar 07 '14 at 16:38
@ebyrob, see it dude http://codahale.com/how-to-safely-store-a-password/ — jean, Mar 07 '14 at 16:44
@jean But one would need to build the rainbow table for each salt individually. That’s the exact purpose of salts. — Gumbo, Mar 07 '14 at 16:54
@jean Perhaps I'm just quibbling about terms. If you generate an entire unique rainbow-table for each user in the database after you get your hands on the password file, I'd hardly call that "pre-computing". — , Mar 07 '14 at 16:55
That's just more one dimension on the rainbow. A table can get n dimensions, use one for user, other for possible passwords, another for salts and go on — jean, Mar 07 '14 at 16:59
@jean I dunno, your own article in wikipedia says this: "Defense against rainbow tables A rainbow table is ineffective against one-way hashes that include salts." Adding a "full-dimension" with 2048 bits.. 1 with 600 0's vs storage of the whole cloud 1 with 25 0's. Math wins. (Unless I totally misunderstand the concept). Which isn't to say brute-forcing my two users to find which is "password" and which is "123456" wouldn't work. Only 2 salts in table though... so I guess I should add some false-positives. — , Mar 07 '14 at 17:08
@ebyrob Yeah i readt that. That article is good to explain basics rainbow table approach but i guess is outdated about using salt against it. Salt can help, for sure, but the only way I see in the long run to avoid rainbow tables are very slow hash algorithms. anyway, no one on USA can use good cryptography. the government prohibits it =) — jean, Mar 07 '14 at 17:14
@jean I can still get to openbsd.org. Although I know our NSA keeps claiming to have "cracked it all" when it comes to secure data exchange. Perhaps they moved from prohibiting to merely discouraging. Which actually seems to have been far more effective. — , Mar 07 '14 at 17:25

Loïc · Accepted Answer · 2014-03-07T20:04:23.563

-5

You may want to take a look at that : https://www.owasp.org/index.php/Category:Attack

SQL Injection and file upload aren't the only attacks you may encounter on your server.

Most known are LFI / RFI, XSS and CSRF, and SQL Injection of course.

Now about MD5, it is a strong method. Thing is, the web is full of dictionnaries which reveals password when given an MD5. To strengthen it, devs usually use salted hashes.

eg : md5("ùmé'l /:'(-" . $password); Then, good luck finding a md5 of even the password "1234" anywhere.

EDIT : This hash is "trivial" to break. Please try this one :

$hash = md5("ùmé'l /:'(-" . $password).md5("&é'à_é('".strrev($password)).md5("&éàç'&àç   /apmq").md5("fu assholes.");
$hash = strrev($hash);

Now have fun breaking that without knowing the formula you md5 bashers.

/EDIT

About magic quotes : It's a false good thing. Your application could still be vulnerable to SQL injection, even with these turned on.

For example if you take the request : "Select * from table where id=$_GET['id']" then one could inject your sql server even without using quotes.

Best thing is not to use magic quotes, and learn to do requests properly. (addslashes strings, and cast integers to integers).

About image upload, the best way to have this safe is to try to get the image dimensions. If it doesn't have any, then it isn't an image, obviously.

Security is important, and it's good to see people concerned with it.

Good luck learning about it.

edited Mar 07 '14 at 20:04

answered Mar 07 '14 at 16:39

Loïc

11,804
1
31
49

3

MD5 is **NOT** strong. It's barely better than plain-text. You don't need to find the password, just something that produces an MD5 collision, and that's trivial. – tadman Mar 07 '14 at 16:39
Have a look at [my answer to *I'm using MD5 to hash passwords. When should I jump to the next thing? SHA-3?*](http://stackoverflow.com/a/12806381/53114) – Gumbo Mar 07 '14 at 16:40
Thank you. This was the answer i was looking for. And sadly most of my native Language tutorial as i already stated keep saying to use magic quotes and MD5. – user3384514 Mar 07 '14 at 16:41
Which language are you looking for material in? – tadman Mar 07 '14 at 16:41
im looking in italian btw – user3384514 Mar 07 '14 at 16:43
@tadman If it’s that trivial, please find a collision for `9ca08f9f1b1c7b89eb21f3dabc8f1f02`. – Gumbo Mar 07 '14 at 16:44
@tadman : Yeah sure. Sources? -Gumbo : "8 alphanumericals characters" ... only my example salt here is 11 characters and there are special chars in it, please let me hash you a password and ask you to break it in 7 hours. – Loïc Mar 07 '14 at 16:44
@user3384514 You can find better and updated resources in italian too, that's not an excuse. – Damien Pirsy Mar 07 '14 at 16:44
@Loïc The salt is considered to be known. So one would only need to brute-force the 8 characters password. – Gumbo Mar 07 '14 at 16:46
@damien pirsy good luck in finding any :) – user3384514 Mar 07 '14 at 16:46
Downvoters make my day. Please show us your awesome h4ck3rZ skills, and break a md5 I'll craft for you. Then tell me md5 sucks or learn to use it properly... – Loïc Mar 07 '14 at 16:50
@gumbo I don't have a GPU-heavy rig here, but you can do several billion hashes per second on a workstation-class GPU. It doesn't matter what you put in there, it could be a 500 letter password, all you need to do is find a collision. Stop trying to justify MD5. **It is completely broken**. Modern Bitcoin mining rigs can do **trillions** of SHA256 hashes per second, and SHA256 is an order of magnitude harder than MD5. – tadman Mar 07 '14 at 16:51
@Loïc If you don't believe me, try [this software](http://hashcat.net/oclhashcat/). – tadman Mar 07 '14 at 16:51
Gentlemans, read it codahale.com/how-to-safely-store-a-password. MD5 is weak as all fast hash algorithms thanks to clouds and rainbow tables – jean Mar 07 '14 at 16:53
I know about md5 cracking. with rainbow tables or gpu fast bruteforcing. But the more characters, the more complexity, now when someone is reading your md5 from your database you have another problem than the md5 itself. – Loïc Mar 07 '14 at 16:53
@Loïc Put down the shovel and stop digging a deeper hole. Write [Bruce](https://www.schneier.com/) an email right now asking about MD5, and if he says it's okay for storing passwords I'll send you $50 in the mail. – tadman Mar 07 '14 at 16:55
@Loïc you got a point, but let's not forget about recent leaks of millions of those hashed passwords from credit cards related companies . I can fell better if they used a slow hash algorithm. – jean Mar 07 '14 at 16:56
3

@tadman The probability of finding a MD5 collision a the given MD5 hash value is 2^127 ≈ 1.7 × 10^38 on average. Divide that by several billion hashes per second and you still have a something with the factor of ≥ 10^27 seconds. I’m not against your statement of not using MD5 for hashing passwords. It’s just that your argument is wrong that it’s *trivial* to find a collision for a given MD5 hash. – Gumbo Mar 07 '14 at 17:04
Plus one could mix md5 to create a hash, let's say with a md5 truncated to 10 characters of the salted id of the user, and another md5 with another salt of the password. Now that you get something of 42 characters, tell me how you know it's an md5, and how you are going to break it. – Loïc Mar 07 '14 at 17:07
@Loïc Read your source or binary that was *also* stolen along with the password file... – Mar 07 '14 at 17:38
@ebyrob You seem to know what you are talking about. Except to read the source you need the mysql read privilege, plus the script being readable by mysql user, AND the usage of quotes in your request. Trust me, you won't have access to all of these conditions often. – Loïc Mar 07 '14 at 18:23
Oh, nearly forgot you also need to find the path to the sources which isn't totally obvious most of times. – Loïc Mar 07 '14 at 19:01
@Loïc If I have your password file, presumably I've already broken through quite a few privileges... It's likely the obfuscation you'll be adding manually won't be nearly as effective as the obfuscation the crypto library authors have given you. That said, there are "double hash" modifications that have extended library life in the past, but only when properly applied. – Mar 07 '14 at 19:21
@ebyrob I don't think anyone is storing md5 password in files since 1978. I won't answer this topic anymore since you guys are truly security experts and there is no way talking with you. Have fun downvoting that. – Loïc Mar 07 '14 at 19:57

Prevention of attack to a website

1 Answers1