April 21st, 2013, 05:42 PM
i have application that retrieves data from database using id.
when you click on search, it displays in the browser the id used in the database table creation
In my database, i have a user with id = 1,2,3 etc.
if i entered 2 from browser, it will fetch the row 2 and so on
Now with the id exposure, i guess the code is vulnerable to attack.
i have enforced SQL Injection and XSS attack protection using function mysql_real_escape_String and htmlentities()
my question is how do i protect this code against web attack of any kind eg CSRF attack,Content Spoofing and many more attacks
$host="localhost"; // Host name
$username="FRED"; // Mysql username
$password="FRED11"; // Mysql password
$db_name="test"; // Database name
$tbl_name="testaa"; // Table name
// Connect to server and select database.
mysql_connect("$host", "$username", "$password")or die("cannot connect");
mysql_select_db("$db_name")or die("cannot select DB");
$sql="SELECT * FROM $tbl_name";
<table width="400" border="0" cellspacing="1" cellpadding="0">
<table width="400" border="1" cellspacing="0" cellpadding="3">
<td colspan="4"><strong>List data from mysql </strong> </td>
<td><? echo htmlentities($rows['name']); ?></td>
<td><? echo htmlentities($rows['lastname']); ?></td>
<td><? echo htmlentities($rows['email']); ?></td>
// link to search value of id
<td align="center"><a href="up2.php?id=<? echo htmlentities($rows['id']); ?>">search</a></td>
April 21st, 2013, 06:32 PM
That's only a vulnerability if the user isn't supposed to be able to view row 2. If they aren't, then you need to code to check that restriction according to your business logic.
April 21st, 2013, 07:00 PM
I see no big security holes in your code, but several potential issues and bad practices:
- If possible, don't use the old MySQL extension (mysql_connect(), mysql_query() etc.). It's obsolete, and there are many ways to screw up the manual escaping (you can forget it, you can you can stumble upon encoding issues etc.). Instead, switch to PDO or MySQLi and use prepared statements.
- Avoid mixing PHP and HTML. This makes it hard to overlook the code and easy to miss a variable that needs to be escaped. Put the PHP on top and the HTML below -- or even use a dedicated template engine.
- Always pass the character encoding to htmlentities(). If the default encoding doesn't match your actual encoding, this can break the whole escaping mechanism, because the function simply doesn't detect the dangerous characters. This has happened in reality.
- Do not display internal error messages like "Couldn't connect to database", especially not with this terrible "or die()" stuff. This leaks internal information and can help attackers. Apart from that, it irritates legitimate users, and it's simply bad programming. You'll probably say it's just for testing, but stuff like that should never be in your code. There are cleverer ways of debugging.
- Avoid storing critical information in variables or constants. There's a risk of accidentally leaking it. Simply write down the data directly where you need it and nowhere else.
Also check the links in my signature. They might be helpful.
By the way, kudos to you for caring about security and actively trying to improve it. That's pretty rare!
Comments on this post
Last edited by Jacques1; April 21st, 2013 at 07:03 PM.
April 21st, 2013, 11:58 PM
how do i check the permissions to ensure that a user do not query other users records.
even with login form, the query is still possible. can you give a little code on how to do that. i dont want to use session variable because session hijacking can be too difficult to handle and i dont want to use https
can id randomization helps
April 22nd, 2013, 12:19 AM
How do you know who is logged in if you aren't using sessions?
April 22nd, 2013, 08:13 AM
I recommend you to start using codeigniter. Not only on security, you will also learn a lot about mvc, active records, database classes ( new tech ) and tones of other things.
Originally Posted by mutago
It is VERY easy to use and learn. As I mentioned you will learn how to seperate pho from HTML and database models.
You will save lots of time.
April 22nd, 2013, 08:26 AM
I think you really misunderstand something, mutago.
First of all: If you don't use HTTPS, then all your security features are pretty much useless. An unencrypted login process means that the plaintext password will travel all the way from the user's PC to your server. Anybody in between can fetch it. It also means that there's no way of telling whether the communication is authentic. You don't know if the request from your user has been manipulated. And your user doesn't know if the response from your server has been manipulated. An attacker might intercept all traffic and change it in any way he/she wants.
So if you want actual security and not just some vague feeling of security, there's no way around HTTPS (or an equivalent protocol). You don't necessarily have to use it for each and every page, but you'll need it for the critical parts like the login process, the user settings etc.
Secondly: I don't know who told you that sessions are evil, but anything that involves privileged access to your website after a login is a session, simply by definition. You may not use the built-in session mechanism of PHP, but then you'll necessarily have to write your own session implementation (which I advice against).
The problems of sessions are the inherent problems of authentication. People can steal your car key and then drive away in your car. Will you now never use a car again? People can steal your ATM card and get acess to your bank account. Does that mean you never use a bank account again? No. You make sure that those things don't happen.
Improving security is great. But throwing away established solutions just because you've heard of problems is not. Trust me: Any homegrown alternative you may come up with has 10 times as many problems. In fact, there's a good chance of it being completely broken.
So do use sessions. Read up on how they work and make sure you've configured them correctly. A good resource for security best practices is the OWASP. And if you got a concrete question, just create a thread.
Comments on this post
April 23rd, 2013, 12:36 AM