Tag Info

New answers tagged

2

Error and Problems in your injection The problem is that you cannot execute multiple queries with mysql_query, and as you are injecting a ; you have multiple queries. The first one is SELECT * FROM users WHERE id = '2' ORDER BY 1 and the second one is --''. The first one is the one that gives you the actual result in the command line, and the second one ...


1

There are possibly two issues with your attempt that cause it to fail: Syntax for MySQL comments to the end of the line --  requires a whitespace or control character following the double-dash: From a “-- ” sequence to the end of the line. In MySQL, the “-- ” (double-dash) comment style requires the second dash to be followed by at least one whitespace ...


0

Any input to the user, whose content may be used in a database query is a possible vector of SQL injection. For example, with your example URL, depending on your server implementation this might work: https://testurl.com:1234/webservicename?parameter=DROP TABLE users;SELECT The key to preventing SQL injection is simple and we'll understood, always use ...


1

SQL injections have nothing to do with whether or not your application accepts URL parameters. They work with any input, be it the URL, the request body, a cookie, an HTTP header or even data from your own application (e. g. a string stored in your database). It doesn't matter. So it's not about the origin of the input. It's what you do with the input. If ...


0

No, because SQL Injection and Insecure Direct Object References includes the case of 'ability to run SQL that the user has access to but the application was designed to not allow'. Your method will limit the ability to get at stuff outside their permissions, but in most cases that includes things that aren't intended to be open, as well as system ...


1

Not effectively, no. You're always going to have cases where row-level security can't properly emulate the business processes. You'd also need to have a lot of "general purpose" accounts for things like user signup. The whole thing would be convoluted, difficult to maintain, and largely ineffective. Keep in mind, also, that SQL injection potentially does ...


0

A little late to the party - I recently read that the reason for this is that for many banks, the value of the increased security of allowing those characters is outweighed by the implementation cost and the support cost of dealing with customers that cannot remember their passwords. I'm not saying that its a good reason, but that is how I interpreted ...


0

If you use userName: ' OR 1=1 -- . password: whatever You this query SELECT * FROM users WHERE userName='' OR 1=1 -- .' AND password='whatever' ' closes the string OR 1=1 makes it ignore that userName='' does not match anything With -- . you create a comment so it does not matter what comes afterwords. The . is just in case you use this not in a form ...


3

This seems like it is actually a direct object reference vulnerability as you are not injecting any SQL to exploit the vulnerability - just providing whatever ID you want. Based on the code you have provided there is no way to delete from another table unless the database has cascading deletes setup or something like that.


1

As others have commented, you need to pay attention to the resulting SQL statement. With a SQLi you're typically only needing/wanting to inject on one field. As @schroeder noted, your example input ends up essentially with SELECT * FROM users WHERE userName='' OR '1' = '1' AND password='' OR '1' = '1' being sent to the SQL server. The AND and OR ...


2

If you are injecting both fields at the same time: Think about the SQL string with the replaced text: "SELECT * FROM users WHERE userName='$usr' AND password='$psw' " becomes "SELECT * FROM users WHERE userName='' OR '1' = '1' AND password='' OR '1' = '1' " Can you run that query from a SQL prompt and get a response? I think you might find that the ...



Top 50 recent answers are included