New answers tagged

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'...


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

The token should have at least 72 bits of entropy (9 bytes, or 12 Base64 characters) This should be generated with a Secure PSRNG (random number generator). So don't use the simple rand() operator of your programming language as it might be predictable, but look for the Secure random generator that PHP provides internally , or read bytes from /dev/urandom ...


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 ...


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.


1

If you ensure your token contains enough entropy (> 128 bits), then you shouldn't need to check user ID as well. I would also store the token hashed within your database using something at least as secure as SHA-2, that way if your remember-me table is compromised in any way, an attacker can't hijack sessions. The cookie set on the client should be the raw ...


2

As long as you have chosen a sufficiently large CSPRNG for the token, checking it should be sufficient. Somewhere in the 128 to 256 bit size should be sufficient. You don't mention where you're storing the token in the user's browser. Cookies are typically used for this. You should have the Secure and HttpOnly setting on the cookie. Basically, you should ...


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 ...


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 /*...



Top 50 recent answers are included