I Just noticed that my mysql_real_escape_string function is not inside a '' in some of my php scripts and it was vulnerable to injections and things like sleep(30) executed on my production site.
I am going the PDO route and implementing the prepared statements after lots of reading here. but this is not implemented yet.
Few questions, I see in my logs that lots of injections where done by people online but I can not see any damages. the user that the site runs to do sql queries has update/select/delete/insert only privileges.
But I am woried things like sleep(30) and what not works and if they did any damages I am not seeing?
Can you tell me where to check for damages or was I safe for at least major damages?
Can they have changed hidden mysql settings or system settings?
By the way, I tried to run latest updates on centos 6+ linux and php.
Thanks
edit:
just to clarify, the database is empty almost and i am not worried about the data being there and the passwords are hashed sh512. so the data inside is not important since this is a new application i am writing. but i am worried if they changed anything on the system or the db i should be worried about. some of the injections i see have java etc but the log is huge and its going to take time to go over it. i also see some schema strings in the injections.
now the question is can they have read my schema info or modified them? why does functions like sleep are working if it is a restricted user? what other functions could they have run?
note i have other DBs in the same MySQL. should i be woried about those?
by '' i mean:
select * from dbname where id=scaped_string
i should have put it in quotes
Checking for damage done to your data is dependent on the kind of data you have in your database. If after careful inspection you don't see anything wrong, then there is probably nothing wrong. If your data is of any decent size, this will be difficult or impossible.
There are many automated bots roaming the internet looking for code vulnerable to SQL injection attacks. Their attempts are probably what you are seeing in your logs. Just because an attempt was made does not necessarily mean an intrusion occurred.
Also keep in mind that you won't necessarily have evidence of data being stolen. The best way to determine this would be to take your server logs and replay them on a copy of your current server, checking to see if you get any data back.
Without any further information, we have to assume the worst case: An attacker is able to read, write, and delete arbitrary data in your database, and possibly even files on your file system, which may lead to compromise of your whole server (e.g. command execution via PHP file, privilege escalation, etc.).
Now let’s have a closer look at the possible impact:
Since PHP’s MySQL extension does not allow multiple statements, so called stacked statement attacks are not possible. So the remaining possibilities depend on the actual statement verb and the context, i.e. the clause inside the statement:
SELECT statement:
Reading any accessible data (e.g. sub-queries, unions, boolean-based blind, etc.)
Reading files (LOAD_FILE())
Writing files (… INTO OUTFILE …)
UPDATE statement:
Obviously updating any accessible data, possibly not just in the current table
Reading any accessible data (e.g. sub-queries, boolean-based blind)
DELETE statement:
Obviously deleting any accessible data, possibly not just from the in the current table
Reading any accessible data (e.g. sub-queries, boolean-based blind)
INSERT statement:
Obviously inserting arbitrary data
Reading any accessible data (e.g. sub-queries)
Some of these may not have a direct impact but may be used to exploit other vulnerabilities. In the end, it depends on the actual vulnerable statement.
As far as I know, there is not hidden mysql setting other than sanitizing your inputs to protect your data from being injected.
You said, you saw lots of injections done by people into the site, and yet you can not see any damage, maybe they were just injecting a plain HTML tags, or trying XXS attacks, because the real mysql injection, can delete your tables, update, reset every data subjected to mysql injection, so if I were you, I would implement PDO right away.
If you have anything like admin panel you should check for webshells and other backdoor-like tools on your server, because attacker could easily read your credentials from appropriate table. And, ofcourse, look for any changes in your pages (look for iframes and suspicious JS code).
Worst case scenario is executing INTO OUTFILE in writeable directory and then accesing it via local include or directly.
But, first of all, before worrying you should consider this as most common automated sql-injection checkers (bots you might say) and if you don't see any damage - mose probably there was no intrusion. But be careful - most intruders nowadays don't look for any visible damage, most probably they will inject some malicious code in your pages (like iframes with their exploits).
So, don't be too paranoid, but still cautious :)
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've searched around and found a way to do exactly this. But I'm hesitant because I occasionally read that its a "security risk". Unfortunately, nobody ever elaborates on why. I, personally, can't think of any security risk that wouldn't involve an attacker already having permissions they shouldn't. The MySQL/PHP servers are running on the same machine. so there's no public requests between the MySQL and PHP.
The PHP script triggered, will make an API call to a web service on a third-party CRM/ESP that keeps a simplified version of certain tables on a their server. Our marketing team could then log into the CRM's GUI and send emails, gather information, and plan marketing campaigns without the need to bother the dev team.
The tables on this server do not mirror ours, they contain only information they would need. The reason I want to use triggers is to keep their information as up-to-date as possible and have that logic in one place, instead of scattered throughout the project.
UPDATE:
I always sanitize/validate any Forms that touch MySQL. I never store PHP in my tables. I never use FTP (SFTP using a .pem instead of a password).
The script that will be executing will be a single file I created that won't change which is going through the same framework I'm using (zend). The only variables passed to the script will be the row's id (which will be validated as an INT).
I'm thinking of not doing this because of performance. And making PHP execute Asynchronously is possible, but difficult and not worth my time to implement. But I'm still curious, Other than the performance penalty, how would the security concerns be any different than say a web service? I mean you definitely have to sanitize/validate just like you would a web service, so given that, what concerns would there be?
There are different ways your app can be compromised, such as SQL injection, a sniffed FTP password, or a vulnerability in the code itself. It is generally a good idea to keep these things as localized as possible to prevent a breach in one area from cascading.
For example, say that you are storing sensitive data in your database. Typically, you would encrypt this data somehow, using a salt and key that is not stored in the database itself. Then, if your database is compromised by SQL injection, the attackers may cause damage, but they will not be able to steal the sensitive information. However, if you are executing PHP stored as text in your database, the attacker will certainly realize this and update it to execute his code, from whence he can figure out how you are encrypting the sensitive data and unencrypt it.
In short, SQL injection is very common (even if you are following best practices, nobody says the intern who walks in next year will) and it is therefore not safe to execute code stored in a database.
EDIT: after reading your link more closely, I need to restate some things. I don't see a particular security risk in this, but this seems to really contravene the separation of data and logic. Further, mysql is not async and there is no way that this can possibly scale under load...
I have my own cms, I'm exploring the security options which I should implement and study.
All my CMS pages are checking of user permissions based on the UserID stored in Session. I was thinking that how much important is it for me to "secure" the forms inside this pages? I mean the users have the opportunity to write SQL statements so if they would want to like use SQL injections it is not really that hard...
So my thinking is to have only the logon page secured + protection against session hijacking, is that correct or am I missing something?
Forms on the front page, query strings etc are also secured.
Thank you for any inside on this.
Securing web apps is a never-ending task. People find vectors to exploit every day (quite literally) through a combination of tools and methods. When building a CMS, you've got to be particularly careful with:
Users being able to log in as someone who they are not
Users being able to remotely inject permanently into a page (especially when combined with above)
Users being able to modify or extract contents of the database they are not supposed to gain access to
All these have to do with form submission, or more generally, userdata entry. It boils down to one simple precept: never ever trust an user.
The first one you have to worry about, and by far the most dangerous, is SQL injection. It's what a lot of companies fall victim to every year, and it is quite in-depth, though most attacks can be prevented by using parametrized queries (TRUE parametrized queries. PDO by default emulates them, there's a config flag to turn on true parametrization). This will effectively do most of the SQL-relevant sanitization for you, leaving the "sensible sanitization" to you (i.e. making sure that a date is actually a date). This protects you from what people tend to call first-order SQL injection - in other words, direct entry.
Second-order is more difficult. It involves storing something in your database that will then get executed in another statement. The CISCO guide has a good idea of how stuff happens.
That's all for SQL to defeat the large majority of script-kiddies.
In terms of content-filtering, you want to use a whitelisting approach rather than a blacklisting one. Remove everything you do not trust or cannot recognize. In terms of HTML, there's a wonderful tool called HTMLPurify that does exactly this.
Also
Don't make the mistake my boss did. Check for the session immediately, not just before rendering the page after the controller has run.
More of a risk assessment question than technical.
So i have been reading a lot about protecting against SQL Injection. Lets assume i have a large web application that is mostly unprotected and i need to make some improvements to protect against this problem. Read large as lots of SQL interaction using dynamic queries but on few (less than 100 registered users).
My question is... If i have already secured the main login script (the only publicly available user input) using parameterized queries, is it really that necessary to do the same work for the rest of the site? I mean if a potential attacker can't log in, how much other damage can he do?
Assuming of course none of my registered users have malicious intent.
Assuming of course none of my registered users have malicious intent.
Never assume that :) If your users have different rights, one with almost no right could find the way to get admin access... And so on.
Also, protecting against SQL injection does not make your login bulletproof and someone could bruteforce through it or simply have sniffed packets from your trusted users. Make sure you protect your whole application, do not assume that the entry point you planned (login script) is the only one available...
And please use SSL if your website contains or requires any sensitive data from your users.
What makes you sure that none of the legitimate users won't attempt to attack your system?
I'm glad my bank don't think that. Some-one would have emptied my account by now, just by using sql injection attacks.
And even then you should be careful about accidents. If you use parameterised queries, someone using a ' in a value won't cause problems.
It allows type safety in your parameters.
It engenders better programming habits.
It allows execution plan caching. (Without it, every query with a different parameter will look like a completely different query. Not only preventing caching of plans for those queries, but over-filling the cache so plans that really can be re-used get discarded.)
Not only is it more secure, it's more reliable. Other than experimentation and throw-away code, I can think of no project where I would have condoned not using parameterised queries.
Never trust your users!
Even if you do (and nobody can sign up either), there's always the potential of CSRF for instance; an attacker would lead users of that system to a seemingly harmless page with an image. That image would have the following code:
<img src="http://yourserver.com/profile?user_id='; DROP TABLE users" />
My hacking skills are practically zilch, but you can imagine what would happen :)
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.