Is a website which is made in PHP secure than others (eg. aspx etc) ? What are general possible threats / attacks that can happen to a php website and What security enhancements should be done in order to make a website (which is made in Php) secure from hackers and different kind of attackers.Is it safe to host the website with good hosting company or it is more safe to host by own computer.Please discuss in detail since its important for beginners of php to know.

Reply

I don't think there's much you can do in putting security for PHP pages. Visitors of the site can't see the actual codes for the PHP pages even if they have saved the page so there's shouldn't be too much problem with visitors snooping the codes. I think it's more important to secure the database and the server itself. If MySQL is being used as the database management system then user privileges should be assigned so that no user can perform tasks that are not supposed to be done by that user. The server should also be secured and user authentication should be imposed to get rid of snoopers.

Reply

Assuming the PHP engine does process the code, then viewing it is not normally possible; but that's far from the only problem you need worry about. Injection is by far one of the most commonly encountered web-based attacks, where a user can 'inject' code to manipulate the way in which something behaves - for instance, code could be injected to modify an SQL query to extract information from the database which shouldn't be, or even execute a command on the server. You can't simply assume that because the user can't see your code or because the system has been secured against other forms of attack means that it's safe from other such methods.

Anyway, a basic rule of thumb is to ensure that all data entered by the user is 'sanitized'. Whether it's entered in a form and sent via a POST query, or sent as part of the URI itself via a GET query, you absolutely have to ensure that you never, ever directly pass user-entered data to anything, regardless of how insignificant it may be.

One of the biggest pitfalls a lot of PHP coders (not just those who are inexperienced - everyone can overlook small potential issues, especially when working on large projects, such as IPB) fall into is passing GET variables directly to a SQL query. For example, an older version of IPB would, when you selected to 'Quote' another user's post, append to the current URI something to the effect of 'qpid=xxxx', where 'xxxx' was the ID of the post you wanted to quote. Whilst not a problem in itself, IPB would pass this value directly to the database query, so it became something like:



Note that it was in fact far more complex than this, but I don't remember exactly how the query was constructed, and this is only intended as an example. Now, the problem was that the user could alter the value of 'qpid', so it turn modified the query - for example, 'qpid=UNION+SELECT+password_field+FROM+user_table+WHERE+user_id=1'. And I'm sure the danger of that is evident.

So anyway, my point is, you have to make sure you always process and sanitize data entered by users - never, ever, ever, ever, EVER assume that's it always going to be what your script is expecting, because it simply isn't.

And that's Basic PHP Security 101 for today.

 

 

 

Reply

In the world of computer programming and web design.... Nothing is ever 100% safe. There are always ways around the security thats in place or there will be bugs in the server/software. The main thing to do to help is what Spectre said. One thing that helps is for usernames/passwords, always use encryptions/encodings. That will extremely help because if a hacker managed to get username and password, it wouldn't do them any good since they would have to figure out how to decrypt the info. With that said, don't use a basic or really common encoding for those are the easiest to crack.

Reply

Any password encrypted with any common encryption system can be cracked. Take MD5 for instance - it is a one-way hashing algorithm, meaning that once a string is encrypted using this method, it can never, ever be reversed. However, it can still be recovered by hashing lists of passwords (dictionary-based or by brute-force, where every single possible combination is attempted). As an MD5 hash is made up of 16 hexadecimal values (32 byes), which can consist of any of 16 characters A-F and 0-9, there are (16^32) or 3.4028236692093846346337460743177e+38 possible combinations for any MD5 hash in existance (although I remember a while ago there were rumors floating around that MD5 can now be reversed or something). ANYWAY, my point is that although it may be incredibly difficult and take an unreasonable length of time, encrypted strings can be broken

Reply

thank you very much for such a detailed answers..it surely helped me understanding many things...so do u mean that using md5 (random 32 characters) , is the best option so far for the security of passwords ?

Reply

I've not used very many encryption method, but I do know that MD5 is definitely one of the best options. Especially if you encrypt a password with some other method (such as creating your own) method of encryption, then pass that encrypted string to MD5, which would make it even more difficult to crack (especially if you used your own method...or it will be most of the time). However, what's most important is that you prevent any kind of injection attack from happening (which has been mentioned).

Reply