What do I need to learn for creating safe websites?

Hi,

What I need to learn for creating safe websites with php.

Do I need to learn ethical hacking So that I can get to know the ways of hacking

or is there anything else?

First would be how to apply validation properly to all $_POST fields and how to sanitise all other inputs so that only valid values can get as far as the processing.

Second is which escaping function to use when you are forced to jumble valid data with code so that the data can’t be misinterpreted as code.

That should take care of 99% of your security concerns.

i think sanitizing the output in the right context is as important as sanitizing the input. many attacks will harm or destroy your data - but e.g. XSS will harm your users.

Some big things to secure your websites are Web Security, SQL Injection, Directory Traversal, Authentication Issues, Remote Scripts (XSS), Processing User Data – Form Input Verification & HTML Display, Executing Code Containing User Input.

Have a look at some PHP Frameworks because most of the security has been tried, tested and secure.

Learning how to prevent SQL injection is a good start. Once you’ve done that, post back here and ask again.

Sanitizing is an INPUT function - I think you are getting it confused with Escaping .

That possibility doesn’t exist any more - since 2004 it is a simple matter of keeping the data completely separate from the code by using prepare statements and there is then no way whatever to inject anything into the code.

We know you are very fond of prepared statements but you could make yourself clearer - otherwise statements like these are neither helpful to beginners nor are they even true! Of course, the possibility of SQL injection still exists and will continue to exist probably forever - the fact that prepared statements exist doesn’t mean they must be used (or that we are forced to use them) so an unskilled programmer can still inject unsafe data to SQL. Learning how to prevent SQL injection is still a very important skill nowadays.

There are still people/bots scouring the web, searching for sql vulnerabilities. That may suggest that they are still finding security holes in some sites for it to be worth the effort trying.
The tools and techniques do exist to prevent such attacks, but that does not mean everybody knows them or is using them.

Here are some key points about security of a website:-

For database queries don’t use MYSQL if you don’t have extraordinary knowledge in database and hacking.
I suggest you you to use MYSQLI or PDO

I also suggested you to don’t use common username and passwords for database user.

I also like to suggest you to encrypt all the form data imeddiate after taking the input from user.

SSL CERTIFICATE WILL also help you out in security.

The OP has posted some code in another topic:-

And I think there is some room for improvement, security-wise.
I’ll paste it here for easy viewing.

``

<?php mysql_connect("localhost", "user", "password"); mysql_select_db("jixcov"); if(isset($_POST['submit'])) { $username = $_POST['username']; $check_username = mysql_query("SELECT * FROM users WHERE USERNAME='$username'"); $numrows = mysql_num_rows($check_username); if($numrows != 1){ echo('That user does not exist!'); } else { echo('That user exists'); } } ?>

``

The first point, you are using the now obsolete mysql functions, these are no longer supported in PHP and have been replaced by the better, more secure, mysqli and PDO which have been mentioned already.

Next, you are not sanitising user input, as mentioned

$username = $_POST['username'];

You could use preg_replace or the filter functions to do that.
Then the unsanitised data is inserted directly into an SQL query, ripe for an injection. With PDO or mysqli you could use a prepared statement as an extra line of defence.

Prepared statements doesn’t guarantee a direct protection against SQL Injections, but it does help reduce the amount of vulnerabilities against it. Please remember, SQL Injections does not come from the user nor the server side language, it comes from bad coding practices.

When you literally stuff the variable inside the SQL string, you are basically allowing SQL Injections to happen.

There are multiple reasons why it isn’t “working”. It’s because the logic is all wrong. As I have said time and time again, please stop using if(isset($_POST['submit'])), if(isset($_POST)), if(isset($_POST['btn'])), if($_POST), or anything that has to deal with $_POST in general. The proper way of checking whether the form was submitted is if($_SERVER['REQUEST_METHOD'] == 'POST').

Next, again, I don’t get why people always try to compare num_rows to a numeric number. num_rows returns a 0 or a 1. 0 meaning false and 1 meaning true. If the statement returns false, the next line it would automatically go to is the else statement. First if statement is always true and the else statement is always false. Why would you compare it and try to make the false statement first when it will automatically go to else when it’s false?

That’s why the logic does not make any sense when PHP does things for you by default, why reinvent the wheel?

Next, only specify the columns you need. If you are the developer, you should already know what columns your database has. There’s no need to use the asterisk wild card (*).


Just a side note. If you are trying to see if case sensitive values get passed, it doesn’t. If you want case sensitive values to pass and say “That user exists”, then you’ll have to use WHERE BINARY ..... to make it case sensitive.

2 Likes

Okay I’ll reword it.

SQL injection doesn’t exist any more unless you deliberately write your code to allow it by using database calls that jumble the SQL and data together in a single statement.

While the main purpose of a prepare statement has to do with improved efficiency of the database accesses it has the side effect of allowing the data to be specified in a separate call (either bind or execute) and unless the data and SQL are in the same command it is impossible for the data to be misinterpreted as SQL.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.