Tag Info

New answers tagged

-1

Using prepared statements with parameters only ensures that the given parameters are securely passed to the DBMS as intended. Such a prepared statement definitely won’t be injectable. However, when the prepared statement itself utilizes functionalities like stored procedures that contain injection flaws themselves, you’re obviously still vulnerable. But ...


5

The only one that immediately comes to mind is second order injection where a value such as 123' or 1=1 -- is stored in a table which is later retrieved and then used unfiltered in a query. It does usually require the code to not parameterize data retrieved from the database which is not that uncommon as developers often consider this a "trusted" source.


3

There is no need to do extra checks if you are using a prepared statement with parameters. This is the industry standard for preventing SQL Injection in PHP. With the example you provided you would be 100% protected (not 99.9%) from SQL Injection (at least based on what we know today, who knows what the future holds). That said, there are ...


5

To expand on Xander's answer - when you use a parameterized query the parameters are never inserted directly into the statement. Instead, the query itself along with all of the parameters are passed to a stored procedure called sp_executesql. When executed this way the parameters are treated as data rather than being parsed out as part of a SQL statement, ...


7

A more common term for this is "parameterized SQL". You are still taking user data, as you pointed out, but the security lies in the fact that the application knows what is data, and what is executable. When you build a SQL statement as a string and pass it in it's completed entirety to the database, the application simply has to trust that the SQL ...


7

Yes - they can find out the structure of your database using the INFORMATION_SCHEMA. Many online tutorial, such as this one talk you through the process, from a simple exploit to extracting all the data. From a defenders point of view, you could deny access to the INFORMATION_SCHEMA tables - I doubt your legitimate application ever uses them. However, in ...


13

In addition to what Philipp said, keep in mind that SQL injection attacks are quite often done without knowing the structure of the DB, but once a vulnerability is exposed, it can be used to determine the structure. For example, one of the first SQL injection string that was once taught used to be ';shutdown-- This makes an assumption that the data user ...


10

That depends. In some web applications, syntactically incorrect SQL statements result in an error message which might get forwarded to the HTML output the visitor sees. This might give the attacker some information how the query looks. ("You have an error in your SQL query near 'myapp_tbl_users'."). To avoid this, configure your webserver to not output ...


2

It may be possible using select into SELECT id FROM table1 WHERE id = 1 INTO table2 However as the attacker does not directly control the id value the attacker would need another method of controlling this data for the attack to be able to have a meaningful impact.


2

Query stacking, ie select * from tbl; update ... -- is forbidden by most database management systems. In order to enable query stacking in PHP/MySQL, the application must use the mysql_mutli_query() function to execute the query. This function is uncommon in the wild. In SQL injection without query stacking, the attacker is limited by accessible query ...


2

The term you are looking for is "enumeration". There are many ways to enumerate a database, and many tools have this option, too. You can try to craft a query that tests the length of the column name, then iterate through the alphabet. You can query the data dictionary to ask the db itself Use sqlmap Google searches would be easier if you included the ...


3

In general, there are two ways to figure out table and column names: Inspect the software's source code or the tables it creates when installed. Blind guessing -- the username and password fields are often named things like "username" and "password", and are often in tables with names like "users" or "accounts". Sometimes you can get them from triggering ...


0

I totally agree that a picture says more than a piece of text. For the sake of completing this thread, I would like to add the following picture: I guess that says it all.


0

According to the Drupal advisory: This vulnerability can be exploited by anonymous users. According to this answer: I can confirm, that this vulnerability will work with every Drupal 7.31 and lower site, doesn't matter which modules are active. Every drupal form could be used to exploit this vulnerability.



Top 50 recent answers are included