New answers tagged

0

You're allowing direct user input into the query so it is injectable by definition. Use prepared parameterized statements (not to be confused with stored procedures) and filter your input. Here's a cheat sheet for secure query handling It will get you up to speed on sql injection mitigation. https://www.owasp.org/index.php/...


3

This appears to be a case of UNION SELECT rather than inserting your own records. What you need to do is figure out how many columns are being selected (by trial and error.. SELECT 1,2,3...n until you stop getting an error). After that, you inject the query so the first part returns false (no username found). The tricky part: You inject ' OR 1 = 0; UNION ...


2

The error you get is from MySQL, not from modsecurity. It informs you that the SQL statement the server has constructed is invalid. For example, maybe the SQL query is contructed like this: UPDATE clients SET useragent='$useragent' With your example, this would become UPDATE clients SET useragent='brick') order by 15 --+' This is clearly invalid, ...


2

If you're directly using the SesssionId in your query, without escaping the SQL special characters then YES the Queries are vulnerable to SQL Injection. For example, Someone could send request to the server with following cookie : csid=a'; DROP TABLE cscart_sessions; And your SELECT query will execute to drop the table. Or a cookie like this : csid=a'...


0

Your entire premise is flawed. That's a terrible design for the database to begin with. Here's my recommendation for the table structure: CREATE TABLE votes ( id SERIAL PRIMARY KEY, candidate VARCHAR(20) UNIQUE NOT NULL, votes INT NOT NULL DEFAULT 0 ); Fill it a bit: INSERT INTO votes (candidate, votes) VALUES ('Alice',0); INSERT INTO votes (...


2

Funny thing, I've experimented with an online encoding converter. I think you have an encoding problem on the client side. When I embedded the string inside the PHP code, it worked. $test_var = chr(0xbf) . chr(0x27); echo(bin2dex(addslashes($test_var))); Resulted in: bf5c27 The problem is when you get the variable from the URL: λΌ§ after addslashes() ...


0

Depending on whether or not the code that makes these queries is properly sanitizing inputs, you may or may not have a vulnerability. Another factor would be whether the construction of the queries is parameterized or simple uses concatenation. As commenters have pointed out, there is no way to tell for sure based on the information you've supplied.


3

Example 1 & 2 This is because your query is applying this clause: '1'='1/*' If you have a comment character inside of your quotes the comment is not respected by the query parser, you would have to exit the quoted context first. 1 is returned as count because that's how many users have that email address. Try this instead for example 1 (the same ...


6

It's not working because of this: if($counter == 1) The injected OR '1'='1' is valid for every single row, and if there are multiple rows in the table, that $counter check will fail. To get around that, you could do something like this (if I remember my SQL correctly), with anything in $email and this in $password: ' UNION SELECT * FROM User LIMIT 1 -- ...


2

A more common and easy way to comment for SQL injection is to use -- because you have not to close the comment. It also requires only 1 input instead of 2. In this case, an easy injection will look like : Username : xxx' OR 1=1;-- Password : not that important The SQL query will be : SELECT * FROM User WHERE EMAIL='' OR 1=1;-- ' AND PASSWORD='not that ...


0

As this feels as a school-assignment, I would recommend buying one or two of the "basic" web security books which often discusses all of the most popular vulnerabilities. This will make you understand the vulnerabilities better and therefore you can explain them in any way you feel like in the paper. As for the interview part the google form idea ...


1

Well It's not about OWASP Top 10 / Top 20 / Top n, those can be changed over time (xss is more present right now then it was back in 90'), what actually matters at OWASP is there update to the technology methodologies (v.1 v.2 .. v.4) that offer an exhaustive testing plan of a Web based application. If you want to simplify them ... you should take in account ...


4

I believe it's because many developers learn just enough to get the job done, for some value of "done". They learn how to build SQL code, often from outdated online tutorials, and then when the code "works" to the extent that they can say "I can put stuff in the database, and I can generate the page of results", then they're satisfied. Consider this guy on ...


1

No, that is not safe at all. Replacing single-quotes with double-quotes or vice versa will only keep you safe from one type of injection. Also, what if the end user has a legitimate need to enter a single-quote mark? As was pointed out in the comments, you should use Prepared Statements. Below is an example, taken from the Microsoft documentation. ...


2

No, I don't think the pwd field is not exploitable in this example. Since the PHP is passed through PHP's MD5() function, the output will be the hexadecimal encoding of the hash. That means the string will only contain digits and the letters a to f. You can not break out of the quote using those characters. Lets assume that instead MD5($_POST['pwd'], true) ...


0

Is there any sanatisation on the email address input? If not you could put in "example@site.com' -- " into the email field (change the email field attribute type to text in the inspector if needed). This will comment out the password check so as long as a match is found with the email it will return true. SHA512 is better than MD5.


0

This should be a comment, but its a bit long. You seem to think that URLs for PHP servers are somehow different from ASP. Apart from the extension on the script (which is only a convention anyway and not a hard wired requirement, even on MSWindows) there is no difference to how the URL is encoded. Until you have an understanding of the protocol, you're not ...


4

The other answers have pointed to almost all the reasons. But there is something else, which I think is the most dangerous security concern of all. Developers attempt to add more and more features to technologies, and sometimes deviate from the actual purpose of the technology. A little like how a client side scripting language ended up being used for server ...


4

Probably not. As you can see, the query uses prepared statements: WHERE `promotions`.`id` = ? Of course, this is only a small part of the query, user input may be inserted directly into the query in other parts of it, so you should check if the id parameter is vulnerable anyways. This may actually be the case, 2170 and 2313 for example do seem to be ...


1

http://stackoverflow.com/questions/22162350/sql-injection-and-activerecord answers this issue fine. Do not use raw strings in ActiveRecord, use hashes. View http://rails-sqli.org for a complete review of the concerned methods.


0

This question has been answered in the comment Section, But this is a explanatory Answer for anyone who wants to look at. So, Looking at Code snippet we could actually see $login = "SELECT fName,lName FROM great WHERE email= '$email' AND pwd = MD5('$pwd')"; As you can see on the pwd = MD5('$pwd') at the end, the Code actually takes a User Inputted ...


2

Personally I think this is a specific case of a more general problem in programming, that IDE's and languages are overly permissive. We give our developers immense power in the name of flexibility and efficiency. The result is "what can happen will happen", and security lapses are inevitable.


7

Yes, anthropologically, humans are stupid. Yes, politically, the incentive structure does not sufficiently penalize vulnerable applications Yes, the process is flawed-- code is written in a hurry; bad/old code is not always thrown away. And, yes, technically, treating and mixing data as code is harder to do by default. But, there's a more positive view ...


6

Because such security issues are not covered during most 3-year education cycles and equivalent studies, and many developers followed such track (including myself). Given how wide the field is, actually 3 years is not even enough to cope with the actual study program.. So things like security are dropped. It is unfortunate, but since some of the new ...


4

If you use prepared statements correctly, SQL injection is not possible. "If the original statement template is not derived from external input, SQL injection cannot occur." https://en.m.wikipedia.org/wiki/Prepared_statement Unfortunately people usually don't use prepared statements correctly, if at all. SQL injection would be a thing of the past if ...


1

PDO (or other "safe" methods) is no more secure than mysql_ (or other "unsafe" methods). It makes it easier to write safe code, but it is even simpler to just concatenate the unescaped user provided strings into the query and not bother with the parameters.


20

I agree with a lot of the answers, but one very important point isn't made: code doesn't magically fix itself, and there is a lot of code out there which is 17 years old. I have seen many companies write clean and safe new code, whilst the application could still be attacked in some of it's older sections. And worst of all: fixing old code is expensive, ...


242

Because it's not a problem. When was the last time a company with a SQL injection vulnerability got hauled up in court, and slapped with a big fine for being reckless with user data, and the directors' warned, fined or locked up for negligence? When was the last time a company lost a big contract because their company website login page didn't validate ...


8

I think the main reason is that developer training doesn't start with best practices, it starts with language understanding. Thus, new programmers, believing they have been trained with the tools to create something proceed to create the queries the way they've been taught. The next and most dangerous step, is to allow someone to develop anything without ...


7

Firstly no one writes secure requirements properly, they say something like "The product shall be secure" Which in no way is testable Secondly Profession developers are not stupid, and to say so is rather disingenuous, they are all likely to have university degrees, and have been solving problems we haven`t even begun to look out... The problem is that ...


8

Why did SQL injection vulnerabilities not got extinct yet? Metaphorically speaking, for the same reason that car crashes are still around since the very first car in 1895 and even the most innovating and modern self-driving cars today, Tesla model S (on autopilot) or Google self-driving car crash from time to time. The cars are created (and controlled) by ...


0

The example you give results in the value 0 (not NULL) being returned. This is because the query you constructed ended up to be a boolean comparison. The = within the assignment part(s) of an UPDATE statement is a comparison operator, not an assignment operator as you might expect. Injection vote`=1, `vote`=10+`vote results in query UPDATE mytable SET /*...


46

When testing, it is very easy to test for what you expect to happen. For example, when filling in a "name" field in a database you will probably choose something you are familiar with, like "John Doe". This works, and your application seems to work fine. Then, one day, someone names their child Robert'); DROP TABLE Students; -- (little Bobby Tables). Of ...


27

Steffen makes good points in his answer, but I'd like to add to it. The why, I think, can be broken in to the following topics: Lack of knowledge or education of developers Churn in an enterprise development environment Pressure to deliver ahead of schedule Not enough emphasis from the top on security So let's break those down. Developer training There'...


106

SQL injection is still around because the software world still doesn't understand that programmatic generation of tree-structured values (like queries or markup) should be done by constructing syntax trees as first-class objects, not by concatenating strings that represent fragments of a language. There has been a bit of progress in recent years with the ...


387

There is no general fix for SQLi because there is no fix for human stupidity. There are established techniques which are easy to use and which fix the problems (especially parameter binding) but one still has to use these techniques. And many developers are simply not aware of security problems. Most care that the application works at all and don't care ...


0

The other answers are right, but one thing that wasn't mentioned is where you inject. If you inject on a statement that performs a DELETE, you'll risk deleting everything if you inject on it. Likewise, if you inject on an INSERT, you'll risk corrupting everything. When performing assessments, care must be taken to understand the functionality before you ...



Top 50 recent answers are included