I'm not some kind of hax0r or so, but my boss has a website and I told him that it was vulnerable to sql injection attacks. He then responded that it was not a danger, because all the information is public; so I told him that there is the possibility to drop the tables.
Usually the DROP table command works, can someone tell me why not in this case?
NOTE: THIS DATABASE ONLY STORES NEWS, NOT VITAL INFO!
news.php?id=-99%20union%20all%20select%201,2,3,4,5%20from%20information_schema.columns%20where%20table_schema=0x656e6469616d615--
Please, do not reply with hax0r-hate comments, if I wanted to know how to hack I would be on irc channels, not here.
EDIT:
If he's safe from database editing I think he's right.
He could disclose the sql query but that would defeat the purpose of showing him the danger is real.
If you are able to detect columns names from SQL injections, it means it is violatable.
It also means you could easily brute force attack a webpage and detect all the structure, users, export the data, etc... So yeah, site IS vulnerable and it goes much farther than "My data is public so i don't care"...
The hacker could find a way to insert data into the database, create some phishing, steal data from XSS attacks that he inserts into the database. There are tons of reasons to take this seriously. SQL injection doesn't mean that the hacker can only read your data, it can lead to serious compromises...
I'd count any disclosure of information as dangerous - if this doesn't get fixed now, what happens in the future when/if more sensitive information is placed onto that database? What if existing data is modified in a malicious fashion?
SQL Injection is very easy to protect against, and if you know of a possible vulnerability it should be fixed ASAP, regardless of what is deemed sensitive. Just my 2c.
SQL injection isn't a problem if the SQL user only has access to the SELECT privilege. Any other privileges could probably be a security threat (Particullarly DROP, but also INSERT or DELETE).
Personally, I would just protect it all against SQL injection, and then apply privilleges to the SQL user that restrict the ability to perform an attack even if my front line of defences is broken.
Even if the data is not sensitive, SQL injection could lead to phishing attacks, scams, and illegal content being displayed on the vulnerable website. Not good.
Related
I am going to get into database designing and PHP. But when I do I am very worried about SQL-Injecting. Is there anyway to reverse this when it happens. Like auto reset it, or delete the account thats hacked, or close the databases. Also is there a way that it can be Auto-Tested for intruders?
This is an immensely complex question.
Short answer is: No, if no backups exist
The long answer:
You should mainly focus on how to prevent sql injection, for example using prepared statements is a good method to prevent these attacks. Regardless of potential sql-injection vulnearbilities regular backups should be made and stored at a different physical location. The datacenter of the server with the database might burn down and your data is gone. Though this is very unlikely to happen it is not impossible.
Depending on the importance of the data in your database there are ways (for example cron jobs) to do backups weekly, dayly, every hour and so on. If you have a second server you can write a script that sends the backup to the seconds server or you log in from time to time and download them.
You could also log all interaction and changes in the database but reversing the damage done in this way is not practical.
This link might be interesting for you: Prevent SQL Injection in PHP
If you get a SQL injection the attacker gets the same privileges as your application, they can delete or change whatever they want so basically you're out of luck. You can restore your database from a backup but then you'd lose whatever changes happened between the backup and the attack.
Instead of trying to detect and revert SQL injection you'd better avoid allowing them in the first place, a good way to avoid SQL injections is to use PDO's prepared statements.
To put it simply, if it happens, you pretty much already lost. Disconnect the database from the internet and assess the damage, dump the damaged version for later analysis or whatnot, and restore to the closest non-broken backup, is probably the best course of action in most situations.
But what you should do is prevent it in the first place.
While it is possible to do escaping and/or pattern checks, it is much better to solve it with prepared/parameterized statements and/or object-relational mapping.
A lot of the major frameworks comes with some form of ORM, and unless you are either super-confident about covering all security holes or in a situation where security is completely optional, I seriously recommend you to use something like that.
Aside from SQL injection, this will also protect you from a variety of other security risks, and help you in other ways.
For example, have a look at FuelPHP.
I am just reading up about mysql injection and I wanted to confirm that if you force a user to use list options for their input that is written to mysql (and those inputs are set as readonly) is the system essentially secure from mysql injection? would one need to put in measures to protect malicious mysql injection attempts for sites developed this way?
If I understand you correct then no.
You can try to force the user but everything that the user enters, happens on the client side. Since this is on the clients side and the client has absolute control over the webpage he can manipulate it to whatever he wants or even genereate own POST or GET Requests regardless of the page he received.
There are some tools that can achieve this goal.
If you want to secure your database against SQL Injection I recommend that you use prepared statements only (How can I prevent SQL injection in PHP?)
Any countermeasures that you take have to be implemented on the server side. You should always expect that the user sends whatever will break your code and do harm to you, regardless of the "restrictions" he has to his input.
Based on the information provided in the question:
Q: ... is the system essentially secure from mysql injection?
A: No, this doesn't guarantee that the system won't be vulnerable to SQL Injection.
Q: would one need to put in measures to protect malicious mysql injection attempts for sites developed this way?
A: The best measures against a malicious attacker exploiting a SQL Injection vulnerability is to prevent SQL Injection vulnerabilities in the first place.
And that means speicific coding patterns for the database interactions: prepared statements with bind placeholders. Or, at a minimum, properly escaping all potentially unsafe values that are included in the text of a SQL statement.
Your web page can have a drop down list box from which the user makes a choice, and your web page can do validation in Javascript. But that doesn't prevent a malicious attacker from bypassing that, and sending a request that doesn't conform the javascript validation.
The script on the server that handles the request will need to perform the validation... probably the same validation that was done in javascript on the web page that generated the request.
But any database interactions will also need to follow the normal patterns that prevent SQL Injection vulnerabilities (i.e. prepared statements with bind placeholders, or at a minimum, properly escaping potentially unsafe values.)
Multiple lines of defense.
It's not at all clear what you've been reading.
As a starting point, I recommend you review the information available from the OWASP project.
https://www.owasp.org/index.php/SQL_Injection
This isn't the be-all-end-all, but it's a good overview. If you are in a hurry, you can look at the SQL Injection Prevention Cheat Sheet.
In class we're now learning about SQL injection attacks and my professor showed us examples where we either use only the username input for the attack, or both the username and password.
I started reading about SQL injection more and found that you can create attacks by typing 'admin' or 'xx' into the username input and then primarily using the password input for the attack.
My question is, is it possible to perform a SQL injection attack using only the password input and typing nothing in the username input?
EDIT: This question is in the context of using a SQL injection attack on a database via the password box of a login page of a website.
is it possible to perform a SQL injection attack using only the password input and typing nothing in the username input?
Yes.
If you're asking this, then your professor failed with explanation. He's not alone, though.
Most people in the world do confuse the injection and the exploit. Taking one for the another.
What your professor demonstrated to you was exploit. Yes, various particular exploits involve various particular query parts. But the principle of injection is breaking of the query integrity. That's all. As long as you can inject any code into query, it is vulnerable. Will you be able to exploit it or not - that's another matter, one have to learn SQL, not injections for this.
But the point of injection is just breaking of query integrity. And for this matter it doesn't matter, be it password or "remember me" checkbox. Comprehensible?
For the better understanding I'll recommend you an article, I wrote aiming protection from injections, but it surely can help you to understand the injection too. The first three chapters and appendices could be of the most help. Here it goes: The Hitchhiker's Guide to SQL Injection protection
Yes it's possible depends on how code is written to validate . If code is written only to get a true/false result set. You can very much anything to get a true result and get into application . For example select '1' from xyz where username='xxx' or yy=yy
I have a form with one textarea field. The field is set to accept anything and stores the input in the database when submitted. The code is then made public as a url ex: domain.com/asd. I'm not doing any type of strip_tags, htmlentities or any type of xss prevention.
My Question is, what harm can this possibly cause. Can a user do any type of xss to fetch information from the database during either input or output.
XSS does not make any attacks possible against your server which would not be possible without XSS. What XSS does is to enable an unauthorized user to act as an authorized user. If you don't have user authentication on your site, XSS is usually not a threat.
You might be in serious threat of stored xss attacks, Stored cross site scripting :
A Stored Cross Site Scripting vulnerability occurs when the malicious user can store some attack which will be called at a later time upon some other unknowing user. The attack is actually stored in some method to be later executed.
So, if the malicious code is in the text area and you store it. At a later point of time when you display the data stored in the db, its like you are executing the code right. Apart from this, there are a lot other ways to play with your database whenever you use the data from the textarea in your SQL query.
When you accept input from the user you should at least:
for database use PDO to prevent SQL-injections.
use filter to prevent XSS
Otherwise your code is going to be unsafe as hell.
I would recommend you to read OWASP to know more about a lot of vulnerabilities. Especially the page OWASP top 10 is a must read.
Let's not go so far as to say that I'm paranoid, but I've been spending hour after hour learning how to prevent SQL injections (and XSS for what it's worth).
What I'm wondering is that a SQL injection doesn't seem like it would do permanent harm to my database if I've made daily backups. Doesn't importing yesterday's copy of my tables just restore them and then I can be on my merry way?
As far as actual loss of data goes, you're mostly correct - you'd lose any changes made in the past day, but aside from that you'd be back to a functional database.
However, there are other things that, just because they aren't "lost", doesn't mean it isn't bad that they got compromised. These kinds of things are stuff like user account info (and especially password hashes) - things that people use to protect their accounts and, if discovered by the wrong people, can lead to malicious usage of their information and resources.
That's why you have to work to avoid security breaches in the first place rather than simply rolling back any changes.
This is a very dangerous way to think. Yes, SQL injection attacks will usually trash the database and thus instantly crash your web app, after which you (somewhat) merrily restore from backup and go on your (somewhat) merry way.
On the other hand, they may simply blow away or alter a few records at random, so that it takes you weeks or even months to discover that your data have been getting slowly corrupted over a long period of time. Good luck recovering from that.
Worse still, the SQL injection attack might be designed to steal data rather than damage it. An attacker might figure how to get your web site to deliver a bunch of credit card numbers in response to a nominal request to edit their profile.
Yes, unless the table contains user-sensitive and/or XSS-injected data. Then you've another problem to fix. Always sanitize on SQL injections during constructing SQL queries and always sanitize on XSS injections during displaying client-controlled data in HTML output.
Other people have noted that you've partially addressed the issue of data loss (restore from hopefully recent backup) but missed the issue of data theft.
There's another potential issue. Many SQL servers allow you to execute arbitrary system commands (e.g. MS SQL). Others (e.g. MySQL) let you write arbitrary files (see also this article on exploiting MySQL injections). The bottom line is that an SQL injection attack can compromise the whole system, and thence onward. Of course, there are configuration options to disable some of these, but they're real concerns.
If you want recommendations, I suggest PDO with prepared statements.