Tag Info

New answers tagged

1

In this particular example there's very little you could do, even if you hadn't magic_quotes. That's because a SQL injection normally can only add to the query string. Since the string is an INSERT command, you can only INSERT something. In theory, if the SQL server behind supported "chained commands", you could transform a command in two: INSERT INTO ... ...


0

How can I obtain the database's content using the SQL injection technique? Whether or not you can do this will depend greatly on how the information is used after it is pulled from the database. For example, if the information pulled from the database is only used to see if you have valid credentials, but never displays any of the database content that ...


0

That SQL injection don’t work on your server may be due to magic quotes, which escape certain characters in incoming data with backslash escape sequences: […] all ' (single-quote), " (double quote), \ (backslash) and NULL characters are escaped with a backslash automatically. This is identical to what addslashes() does. These are exactly the characters ...


3

You should ensure that you have the right skill set before offering to perform work for a client. This means that you looking at the website will be worthwhile and you won't give the client a false sense of security. This will be better for you as you will know how to take the correct steps to perform a test legally and won't get sued by the client if you ...


2

Yes it is vulnerable. Depending on the input mechanism and the implementation I can simply append a UNION and continue the query to select additional data. I cannot give you an exact scenario without seeing the implementation and the query this string is concatenated with. Fact is that you allow input beyond the scope you will need or want. Just use ...


1

The high level is meant to be the secure implementation and should be unbreakable. Looking at the source code you can see that there is verification that $id is a number. if (is_numeric($id)){ $getid = "SELECT first_name, last_name FROM users WHERE user_id = '$id'"; Therefore it is not possible for the id parameter to be changed to anything ...


1

While the previous answer does explain how to do this, since this appears to be a demonstration problem, it is probably beneficial to give a little more explanation about why it works. This example appears to be a demonstration of the weakness of client side code. In public networks, such as the Internet, client computers are pretty much never trusted. ...


2

Disable your javascript. If your using FireFox: Go to "about:config" then "javascript.enabled" set to "false" If you just need to remove certain javascript as you rely on the other javascript install FireBug and remove the code you don't want.


1

There are cases of SQL Injections leveraging the implicit conversion of Unicode homoglyphs from Unicode character string types (NCHAR, NVARCHAR) to character string types (CHAR, VARCHAR). A character such as ʼ (U+02BC) in NVARCHAR may slip through the escaping routine and get translated to ' (U+0027) in VARCHAR, which may result in an SQL Injection when such ...


2

Please, please, please, please do not use a handmade regex for preventing SQL injection. You should never be writing your own escaping, filtering, or sanitizing functions to prevent SQL injection, XSS, shell injection or the like. These are things you rely on built in and vetted libraries for. Where you can avoid it, don't even use a standard library ...


-1

Yes, everything goes through your ISP he can report attack. But the sysadmins of the site you are attacking and cops will have very hard time tracing you, if you ISP don't report the attack =D.


2

If you're looking at how unicode can be exploited, see this question, if you're looking for a solution, there are really only two that can be considered really secure: parameterized queries and encoding all of your input into hex or base64 or some other encoding that doesn't leave open the possibility changing the context of the value. I would seriously ...


2

The one thing you need most to stop SQL injection is a semi-colon (;). However, it isn't always simple to just eliminate them. You will have situations where a semi-colon is used in a text field as a character, not as a SQL command terminator. There are plenty of articles that go into detail about how to both inject and prevent SQL in your queries. ...


0

Disclaimer: I'm the gem author. I wrote Codesake::Dawn, a security source code scanner for ruby code. I'm close to release version 1.1.0 with 171 security checks (CVE bulletins and Owasp ROR cheatsheet) included. It works with Sinatra, Padrino and Rails web application out of the box. It doesn't detect xss introduced in your code... yet :-)


0

Yes, You can write your shell onto the web server with SQL statements without logging into the admin panel or any other control panel. But for this you have to met certain requirements. 1.Your must have write privileges and a writable directory (where you have to upload your shell) 2.Root Path (i.e /var/www/website/) 3.Magic Qoutes must be enabled Now ...



Top 50 recent answers are included