New answers tagged sql-injection
5
A few notes
An SQL injection attack is when something unexpected is inserted into a database. The types of injections depend on the vulnerabilities of the system.
SQL Query Injection
If the database doesn't have proper permissions, meaning that the web user has full control over the database, then they can potentially do things like replace all records, ...
1
To add to Terry Chia's resources, there's an SQL injection tutorial from PentesterLab which does pretty much what you're after, called From SQLi to Shell. I did it yesterday, it's very good. They offer a couple more advanced walk-throughs too.
1
Any form that takes input and uses it directly in a SQL query without checking to make sure the input is safe would be vulnerable to SQL injection. Being vulnerable to SQL injection is more or less the standard state of being unless you specifically take measures to protect against it in your code.
1
If you like to get into webvulnerabilities, i recommend you to learn some basics about PHP, HMTL, Javascript and SQL.
If you have done this: Getting started with OWASP
11
Don't bother writing your own site for a practice like that. Instead, make use of the plentiful resources on the web.
A good practice target is the Damn Vulnerable Web Application(DVWA) project. The OWASP WebGoat project is another nice one.
4
This is most likely a PHP LFI (Local File Inclusion) attack. The .php.jpg "photo" actually contains valid PHP code that is then parsed by some other script on your site which is vulnerable to LFI.
The other files you found were dropped post-exploitation after the LFI vulnerability was exploited.
You can post the boy.php.jpg for further analysis. Host it ...
-1
You should definitely inform all the stakeholders of your website who might be in danger if any sensitive data was leaked. Also, you should compare your current code with the original code and do a code reversion to make sure any malfunctions that were inserted are removed. Check your VPN and communicate with the authorized people in your company to be on ...
12
If the only user on the database that can change records is root and your CMS uses the root user to perform queries then you have a problem. Your root user should never be used by a website.
Get a limited user which can only access the tables and records he needs to access restricted with the right permissions. If he doesn't need delete or update, then ...
12
Get a known clean version of your site and identify the differences between the known good code the and current (hacked) production code. Study how the changes may have been made and repair.
Update the passwords.
Fix the FTP certificate issue - consider using 2 factor authentication.
Find a way to scan your code for vulnerabilities - peer review or ...
1
This is not SQL injection at all; you are not passing $theVar to a SQL server, but to a shell command. Therefore, mysql_real_escape_string is useless.
You need to employ escapeshellarg, which applies the same concept to a shell string.
In this example,
$theVar = preg_replace("/[\"'%()@$.!&?_: #\/-]/","", mysql_real_escape_string($_GET['var']));
...
1
It all depends on the context in which the user supplied data is inserted into.
In case it’s not a SQL string literal, mysql_real_escape_string would be useless as there is no string the attacker has to break out from and something like a UNION SELECT … with certain whitespace characters instead of the filtered space would still be possible.
Exploiting the ...
1
The only sure way to guard against SQL injection is by using parameterized queries. See: SQL Injection Prevention Cheat Sheet by OWASP.
7
I had some fun "decoding" two queries, so here's how I did it in PHP :p
1) or 1=convert(int,(select cast(Char(114)+Char(51)+Char(100)+Char(109)+Char(48)+Char(118)+Char(51)+Char(95)+Char(104)+Char(118)+Char(106)+Char(95)+Char(105)+Char(110)+Char(106)+Char(101)+Char(99)+Char(116)+Char(105)+Char(111)+Char(110) as nvarchar(4000))))--
So let's start with ...
-1
My preference for high security environments is to require a language translation - that is to say if my app is written in PHP then I pass the query parameters to a non-PHP app to do the query; this adds some latency and computational overhead. If you are protecting Things That Matter(tm) this is easily worth it - if you are protecting lolz maybe not.
In ...
0
What most people don’t understand is that SQL string escape functions are only intended to be used for values that are designated for SQL string literals. This means, you can only put such values inside a SQL string literal like '…' or "…".
These string escape functions are used to avoid user provided input being interpreted as something other than a ...
1
A different way of looking at the problem is assuming that the database will be compromised. If the database is compromised and the password table is obtained, how can reduce the value of the attack by making the data meaningless?
First, of course you want to use a strong cryptographic hashing algorithm (bcrypt, scrypt, etc.). You want to use a random salt ...
2
The scheme you describe is similar in concept to making a dedicated password verification server (local server, not open to the world at large) with its own, completely distinct database for the storage of hashed passwords. This can work. Actually you already have that under the guise of "system integration" when the user accounts are mapped, for instance, ...
1
Continuing from my rant in response to Polynomial ;) ....
Proper escaping of parameters of parameters is a very basic preventative measure - and using parameter binding is one way to achieve that.
Another (complementary) approach to protecting your data is to disallow direct interaction with the underlying data to the session from the logic tier - don't ...
1
Web Application Firewall like Modsecurity is just an operation security measure to protect web application from malicious input. WAF is just an application layer filter that can compare each request and response with the malicious signature provided my the WAF ruleset. Modsecurity Core Rule provides comprehensive generic rule set against different attacks ...
5
The only generic approach to preventing SQL injection is to use parameterised queries, also known as prepared statements. These essentially separate out the data from the query language at the protocol level, so the DBMS software will not try to parse any query language from the parameters.
The mechanism you described looks like it's filtering requests with ...
-3
For non integer values I have been doing this, it may not be the fastest but it has worked for me... preg_replace("/[\"'%()@$.!&?_: #\/-]/","", mysql_real_escape_string($_GET['var']));
While i have never seen anybody suggest using preg_replace I see absolutely no way to get around it to perform an injection attack
4
No, escaping quotes/double quotes doesn't guarantee, that your web application is not vulnerable. It also depends on SQL-queries you used.
I have already seen a lot of examples with addslashes() and escape()-like functions where people do like this:
SELECT * FROM a WHERE id > addslashes(user_input)
This is of course vulnerable, because you don't need a ...
3
Your query is first-order-injection maybe-just-maybe-safe, depending on how CodeIgniter improved from the last time I used it.
Let's be clear on this: no amount of sanitization will prevent you from SQL injection. The true "best fix" for PHP is parametrization, which allows you to take the variables out of the query. Failing that, however, proper ...
2
You can segment your tables into sensitive and general. Sensitive tables should not be "Exposed" but "Aliased". In the long run however, your solution is only as secure as the value it holds for the person interested in getting in.
7
More information you expose more vulnerable you are, no matter of his priority in your security policies.
11
Exposing table names might have broader consequences than you expect. For instance you could be putting your company at legal disadvantage by disclosing a table names like "deleted_messages", "profile_views", "single_female_users" etc. Retention of that data and user privacy suddenly becomes a topic of discussion and can cost much.
You cannot always control ...
42
Think about it this way
On one hand, there's nothing wrong with it. If your application is secure enough against SQL Injection, then an attacker won't be able to do much with that information. Unless you're naming your tables table_2231 and your columns column_4231 (in which case I hate you), it's not gonna be difficult to guess your tables names anyway. ...
1
First, determine if you can use a 'create' statement in a query like that.
-1
I can try to give my view of the problem above as a UI interface designer and not a programmer: the key point here is that the login requirement is partly a UI interface design problem and not a programming only problem.
There's an excellent book "Apress - User Interface Design for Programmers" which shows an analogous problem related to window sizes which ...
2
It appears that the attacker was trying to do some investigation into what sort of attacks were possible with the vulnerability he had found.
Regardless; the lesson is always the same: use parameterized queries. If you have to remember to quote and escape your data, then you're doing it wrong.
If you'd like to learn more about how typical SQL injection ...
7
The mere fact your DB ran the quoted queries (throwing you the error reports) means you do have injection vulnerability in PHP code. Note, that some methods of inspecting DB tables structure involve running multiple queries with different parameters until DB throws an error and HTML page breaks. That means the failed queries are only tip of iceberg of all ...
5
Which makes me glad to know that I'm knowledgeable enough in my php to know how to prevent these things.
This is an extraordinarily dangerous mindset to take away from this incident.
That the attacker doesn't appear to have deleted data doesn't mean they didn't read data they shouldn't have. And the fact that they were able to enter inputs that caused ...
-1
yes it is
you are not validating nothing
you have to user mysql_real_escape_string to prevent sqli & htmlentities/htmlspecialchars to prevent xss
take a look at this tutorial as it helps on learning to prevent sqli http://www.thecodertips.com/2012/08/sql-injection-security-tutorial-web.html
3
There's a few things an attacker could do with that code that you might not want.
If their input is SQLITE_MASTER then they could retrieve metadata.
If their input is databasename.tablename, then they could retrieve data from another database.
If their input is (select load_extension(...) from tablename) they might be able to load an extension.
Or they ...
0
Sometimes you do have to concatenate strings to make SQL statements. You must of course be very careful under such circumstances. Variable table names are one such situation.
You should probably in this case use a built-in like quoteIdentifier to ensure you cope with all necessary circumstances.
...
3
The easiest way is to use blind sql injection. You know if the question you are asking is right or wrong depending on how long the query takes to execute. This is also the most flexible approach because a blind sql injection exploit will work regardless of the type of sql injection being exploited (blind, non-blind, select, insert, update, delete....).
...
0
The easiest way is to access the page with legit input and with the injection and look at the difference. If you know what content is not results and know what the format of the expected result is, it isn't that hard to pick out the details with things like regular expressions or some other parsing engine.
Granted, any other dynamic elements (such as ...
Top 50 recent answers are included
