Question

I have pages that only display data from DB tables, the php pages only display the information they don't have any buttons, links, drop down menus, or forms.

Im using the old mysql and not the mysqli or PDO for syntax

Can I still get a SQl injection hack?

No correct solution

OTHER TIPS

In order for SQL Injection to work, they need a way to send SQL Code to your server, as there is no input, it is in theory impossible for them to Inject SQL. (Although I am not an expert in the subject)

I would still recommend you to use a framework like mysqli or PDO, you should familiarize yourself with such frameworks as they became the norm in website design.

SQL Injection works by injecting strings into the SQL you're executing.

This is easiest if the application presents you with a nice text box whose content it glues into a SQL query, but it's also possible through other means.

For instance, if your reporting application uses any kind of the HTTP request to show data, an attacker can use WGET to spoof the request and inject SQL. For instance, if your reports have a URL format of http://myserver/report.php?month=february and you use february to build a SQL query, you're vulnerable.

It all depends on the query source. If ANY part of your SQL query comes from a user input (in other words; if not your whole query string is a string constant) then you are not safe.

For example:

SELECT * FROM USERS ;
SELECT * FROM myTable WHERE id = 5;

is safe but

SELECT * FROM myTable WHERE id = (some variable derived from user input like querystring or post-form)

is DEFINETELY not.

You should use

SELECT * FROM myTable WHERE id = @0 

syntax for maximum security. This is the only one proven way to keep safe from SQL injection.

If the query is independent of the request you are safe. Be warned that mean users are very creative. You might have some dependency on user data which you are not aware of. E.g. a script like this might be broken:

$locale = Locale::acceptFromHttp($_SERVER['HTTP_ACCEPT_LANGUAGE']);
$sql = "SELECT * FROM entities WHERE id = 7 and locale = '$locale'";

Disclaimer: I'm not aware if Locale::acceptFromHttp() does some validation. Let's just assume for the context of this post it doesn't.

I don't want to say it's not possible to write safe code without prepared statements. OTOH it really doesn't hurt using them.

SQL injection occurs if user-controllable data is used in an SQL statement without proper processing:

The software constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component.

Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.

Note that user-controllable data include any data that can be influenced by the request of a user, directly or indirectly.

Conversely, this means if your SQL queries don’t contain any user-controllable data, i. e., the queries are fixed in code and are not influenced by any changeable input, it cannot vulnerable to SQL injections.

I have pages that only display data from DB tables, the php pages only display the information they don't have any buttons, links, drop down menus, or forms.

I would dare to say that such a setup is just impossible.

The very idea of having a dynamical web-page, served by a php script from database, is to use the same script to show different content from database.

So - either you indeed have only set of static pages (which I doubt) - you need no PHP/database for them then - just static HTML would be enough.

Or - most likely - you have dynamical pages showing content based on user input of some sort - and thus perfectly vulnerable.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top