views:

300

answers:

6

Hi friends,

I have a php file at my site, and I connect to db, get some records and list them in same file.

mysql_connect("localhost", "blabla", "blabla") or die(mysql_error());
mysql_select_db("blabla") or die(mysql_error());

$blabla1 = mysql_query("SELECT * FROM gallery WHERE id_cat=1");
$blabla2 = mysql_query("SELECT * FROM gallery WHERE id_cat=2");
$blabla3 = mysql_query("SELECT * FROM gallery WHERE id_cat=3");

So, is there anything I need to do for security? :/ like sql-injection or anything else. there is nothing going to url. it is just www.blabla.com/gallery.php

appreciate advises!!! thanks a lot!

+4  A: 

As long as your queries don't use parameters, SQL Injection is not a risk. SQL Injection can only happen when the users (or other sources) can influence anything that is send to the database in SQL, for example searchwords

Jasper
Actually SQL Injection can only happen when the **programmer** fail to follow simple syntax rules. And SQL injections has nothing to do with user unput
Col. Shrapnel
How would you perform a sql injection without userinput?
Patrick Cornelissen
@Col. Schrapnel: A developer should always sanatize any parameters before using it in a query. It is true that the data can also come from a other source (eg. a file on the hard disk)
Jasper
but the data on the disk is safe too as long it has never been provided by the user or has been generated from user input
Patrick Cornelissen
@Patrick Cornelissen: It could also be a connection with a other application for all that matters. Never trust anything that you don't have full control over. A file on the disk could also be corrupted by a virus or by a other program
Jasper
Look @Patrick 1. special characters escaping is not an injection protection issue. It is general syntax rule. 2. As Jasper mentioned, there can be other source of data.
Col. Shrapnel
@Patrick "as long it has never been provided by the user" how do you know? Why to guess at all? Anyway, not-malicious-data from disk can contain apostrophes. I don't think you want your query to be broken. mysql escaping is not injection protection but a syntax rule and must be used unconditionally, no matter of data source
Col. Shrapnel
Almost all data on discs has been created from or in direct relation to user input, so it's almost always necessary to escape or even better use prepared statements. You don't need to do it when for example you read only database IDs or you have the data strongly typed (for example as int) in your programming language. Then it's pretty unlikely to be able to inject something.I don't want to advocate to build SQL on your own, I even intended to advocate the use of prepared statements because almost everything has been user input in some way, that's why I wrote that in my earlier comment.
Patrick Cornelissen
+8  A: 

This snippet is perfectly safe, because there are no variables put into the query string.

To work safely in case you have to deal with variables one day - be they directly coming in from the user, or from another data source - you may want to switch over to a mySQL library that supports parametrized queries, like PDO. Those eliminate the danger of injections completely, because they take care of escaping the incoming data automatically.

If you stick with the mysql_* functions, make sure you escape all incoming any data using mysql_real_escape_string() and ensure they are inserted within a pair of single quotes.

Pekka
You continue to repeat the same error again and again. not incoming data but any data.
Col. Shrapnel
@Col you're right. Corrected.
Pekka
not any data but only data that going to be enclosed in quotes :) It is simple rules but everyone keep forgetting some part of it. That's why unconditional use of parametrized queries considered better practice.
Col. Shrapnel
+1 For POD and prepared queries.
Colonel Sponsz
+2  A: 

There are no security issues here. SQL injection might happen where you get input from the user and use it in your queries.

celalo
+1  A: 

This snippet is safe, as there is no user provided input in the queries.

if you have userinput, for example by getting the category that should be displayed from the URL or from POST you should use prepared statements. this may you are safe even with user input. This is much safer than pure escaping because the sql is parsed and then the parameters are inserted. This is better for performance and the userinput can't change the structure of the sql query.

Patrick Cornelissen
+1  A: 

if gallery table contain some user input, then some XSS attack may be conducted. To prevent this, all untrusted user input must be prepared using htmlspecialchars() function before printing to the browser.

Col. Shrapnel
A: 

The only thing that you might want to consider, assuming that the connection code is in the web-accessible PHP script, is to either:

  1. move the MySQL connection out of the script and into a file outside of the site's document root

  2. or, use externally-sourced variables (i.e. from a different file outside of the document root) for the username and password in place of hard-coded details in the script

That way if, for whatever reason the server displays the code instead of rendering the PHP, then the details will remain safe from view

Cez