We all know it is nearly impossible to produce a large website without one or two flaws. As such I've written a small monitor that checks Apache access logs for potential SQL injection attacks (amongst other things), and it's working very well. I get an alert whenever someone attempts an attack, and I've had so few false positives that the default action is now to dump them into an iptables drop list. It's even helped me identify a few (non-security) bugs and remove them.
Here's my rules (case insensitive):
PathInjection = \./\.\./(bin|boot|data|dev|etc|home|lib|lib64|media|mnt|opt|proc|root|sbin|selinux|srv|sys|tmp|usr|var)/
Havij = 0x31303235343830303536
r3dm0v3 = 0x7233646D3076335F68766A5F696E6A656374696F6E
LogicBypass = '.*?(\bor|\band|\bxor|\|\||\&\&).*?--
UnionSelect = union[^a-z-_]+((all|distinct)[^a-z-_]+)?select[^a-z-_]
What I'd like to know is, how would you bypass these checks and still produce a valid injection? Can you think of a way to improve them without introducing false positives?
A few notes:
Case sensitivity is switched off.
I'm using MySQL.
The Havij and r3dm0v3 entries are used as a catch-all to prevent use of those automation tools.
I'm checking both raw and urldecoded strings.
I'm not looking for answers like "make more secure code instead".
I'm not looking for a different way to do this, just a way to improve my current logic.
EDIT:
Ok, so people seem to have misunderstood my intent. That's probably my fault, since I didn't fully explain. This is being requested as a tacked-on feature to a monitoring product, and is designed to offer minimal security monitoring. As part of our dialog with the client and our documentation, we're emphasising that this is not a catch-all, nor is it a replacement for proper security infrastructure (e.g. an IDS and firewall). It's simply an informational service to help provide basic threat detection and produce statistics about the number of potential attacks. I'm not trying to write an IDS or firewall. If it were up to me, I'd leave the feature out and tell them to go install a full suite of security infrastructure with its own monitoring systems, but this isn't my call. The current situation is that I've been testing the system on my own site. Right now, I'm just looking for a way to improve the regex strings to make this more effective. Hopefully this clears things up a little.
Edit again, in June 2021.
I posted this question back in 2011. Back when I wrote it I was a junior developer with an interest in security but lacking experience. Since then I've switched careers to security, worked as a pentester for 5 years, and a security researcher for another two. I'm also one of the top reputation users on Security StackExchange.
The answers given here are mostly correct - there's far more value in deploying something like ModSecurity with appropriate rules, since they've already done the work. A tacked on homebrew solution is not going to compare to a project with almost two decades of maturity.
The one major caveat, though, is that I was not making the decisions. Junior developers usually have neither the privilege nor latitude to veto product decisions made by management, especially those made at the request of a customer. One can certainly explain why an idea is bad, and provide supporting material, but that often doesn't translate into changed decisions. Being able to refuse a task from your employer without consequence is an unusual privilege - the concept is a complete fantasy in the context of most employment.
My advice for folks who respond to these types of question is this: explain why it is ill-advised, but be sympathetic and helpful to those who are in a difficult position. Actually answer the question, wherever possible, so that a best-effort solution can be implemented if all else fails. In the context of security features, it's also worth considering that if the alternative is no protection or detection at all - even if that alternative is artificially being imposed by external actors - a weak capability is almost always better than no capability at all.
I don't remember what I ended up implementing for this. It was so long ago. But if you're here now, looking for answers, I recommend using ModSecurity. They now have connectors for Apache, nginx, and IIS, so you can install it on any of those web servers. If changing the server configuration is problematic, you could instead run nginx as a reverse proxy with ModSecurity enabled, so that users hit the nginx server and it proxies the requests to your actual web server. This can also be done with Apache instead.
If you're looking for a more programmatic approach, ModSecurity has language bindings for C, C++, and Python. The ModSecurity API can also be consumed via any language that has interoperability support for C APIs (e.g. P/Invoke in .NET, or JNI in Java).
ModSecurity works on rules. One of the best free rule sets out there is OWASP Core Rule Set (CRS). The rules are significantly more powerful than simple regex patterns. This makes them very effective, but it also means that you probably shouldn't try to build your own ModSecurity-like internal feature that consumes the rules, because you'd need to put in a ton of work to support all the necessary features.
If you need to parse ModSecurity logs into a format that can be automated upon, take a look at ModSecurity Log Utilities.
Hopefull this info is of use to someone in future.
You're talking about writing an IDS. Unless your product is an IDS, just get and install one. Snort is well-known and has a free version.
I'm not looking for a different way to do this, just a way to improve my current logic.
Sometimes when it comes to security, the wrong approach simply is. How would I mess with your current logic? Unicode or hex encoding.
Here is a nice example of IT threat detection using deep-neural-network vector embedding and a similarity search engine.
Can you think of a way to improve them without introducing false positives?
I wouldn't think of improving this silly approach at all. I'd rather improve the site security itself.
We all know it is nearly impossible to produce a large website without one or two flaws.
I disagree with that. At least for SQL injections. Injections are quite silly thing and protection is not a big deal.
sql injection is top rated web Application attack these days. There are many insecure code over the net and also there are several ways to protect application from sql injection attacks. sql injection can occur when an application uses input to construct dynamic sql statements or when it uses stored procedures to connect to the database. Methods of sql injection exploitation are classified according to the DBMS type and exploitation conditions Vulnerable request can implement Insert, update, delete. It is possible to inject sql code into any part of sql request Blind sql injection Features of sql implementations used in various dbms. Successful sql injection attacks enable attackers to execute commands in an application's database and also take over the server.
my recommendation:
Basically, make sure your web server is up-to-date with latest security fixes/patches.
Make sure you have filter every user input and output as proper encoding like UTF-8.
Read the full testing guide: https://www.owasp.org/images/8/89/OWASP_Testing_Guide_V3.pdf
try tom imlement web application scanner , check this link http://trac.ush.it/ush/wiki/SecurityTools
I do ex. watchfile now IBM aapscan tools http://www-01.ibm.com/software/rational/offerings/websecurity/ to scan all my web application
check google more how to protect against sql injection
Microsft http://msdn.microsoft.com/en-us/library/ms998271.aspx
http://www.sans.org/ "sql injection"
WASC: http://projects.webappsec.org/SQL-Injection
OWASP: http://www.owasp.org/index.php/SQL_Injection
CodeProject http://www.codeproject.com/KB/database/SqlInjectionAttacks.aspx
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I was wondering if there is a standard way to tackle SQL injection. I'm asking because I started working at a company and they want me to make the website sql injection safe. Is there way to e.g scan the whole website or procedure to tackling SQL injection in a software that already exists?
I wrote about SQL injection defenses extensively in a presentation SQL Injection Myths and Fallacies (or listen to me present it in a free webinar at Percona.com).
There's basically no silver bullet, but there are several standard methods of defense.
Penetration Testing
There are a variety of free intrusion detection tools available, such as WebScarab or w3af. These can be a good first step as a black-box testing technique for finding the first layer of vulnerabilities in your website.
Another good article on the subject is Web Application Security: Testing for Vulnerabilities from IBM DeveloperWorks.
Code Analysis
Can we scan the code of a whole website to detect SQL injection vulnerabilities? Yes, there are many code analysis tools available. Which one is best for you depends on the code language you use, and your development environment.
NIST has a pretty huge list of Source Code Security Analyzers.
But even if you use intrusion detection and code analysis tools, remember the old wisdom about testing: Testing shows the presence, not the absence of bugs. That is, any testing is bound to be incomplete, so don't rely only on automated testing.
Code Fixes
Once you find a vulnerability, fix it. There are several coding techniques that help:
Escaping or filtering application variables before copying them into SQL code.
Preparing SQL queries with parameters in place of dynamic values.
Whitelisting content that can't be escaped or parameterized (like valid table names or column names).
These defenses are each very useful, but none work in every situation, so you must learn how to use each of them.
There's no substitute for careful code reviews. Basically, for any SQL query that uses dynamic content for part of the query (i.e. copying application variables or any external input into the SQL string), you must make sure that the content has been made "safe" by one of the defense methods I listed above.
Perl has a feature that supports this, for example. Every Perl variable has a meta-attribute of being "tainted" or not, and therefore unsafe to be copied verbatim into SQL (or executed as code with eval or even output to HTML, risking XSS issues). A variable is tainted if it takes any of its value from external, untrusted content. Or if the variable takes its value from another tainted variable (it's infectious). You can "untaint" a variable by filtering it through a regular expression matching function (this assumes you are responsible for making a sensible regular expression that strips off dangerous content).
Other languages don't have this tainted-variable concept, but you can do something similar by manual analysis, tracing the source of every variable that is copied into SQL strings.
Monitoring
Assuring 100% security all the time is incredibly hard. Even if you correct 99.9% of your app's inept handling of SQL, the last case could be the opening a hacker needs. And of course one of your inept developers might introduce another vulnerability tomorrow.
Any security plan has to include constant monitoring for suspicious website behavior. Many of the worst SQL injection disasters were so bad because they went undetected for months while the attackers siphoned away valuable data.
So you have to keep logs of SQL queries, and watch for patterns of invalid queries. For example, keep a whitelist of known SQL query types that your application code runs. If any SQL queries appear in the log but don't match the whitelist, it might be an illicit query run by an attacker. For more on this idea, see Using the Percona Toolkit to Detect and Even Prevent SQL Injection Attacks.
There are also SQL injection proxy products like GreenSQL that can help to monitor or whitelist SQL traffic transparently.
I'm finishing up my first "real" PHP application and I am trying to make sure it is secure. I'm kind of afraid that since I'm not an "expert" PHP programmer that I might be missing something huge, so I would like to give you some information about my application and hopefully you can tell me whether or not that is the case. So here we go:
I'm using a CMS to handle user authentication, so I don't have to
worry about that.
After discovering PDO shortly after starting work
on my application, I ported all of my code over to using prepared
statements with PDO.
I am escaping all form and database data (even stuff I think is safe) which is being output with htmlentities().
My application does use a session variable and cookie variable, but the function of both is very unimportant.
I have designed my form processing functions in such a way that it doesn't matter if the form were somehow altered, or submitted from off-server (i.e. I always check the data submitted to ensure it's valid).
I have done my best to make all error messages and exception messages polite but very obscure.
I'm forcing pages with sensitive information (such as the login page) to be served over https.
When I first starting writing my application, I didn't know about prepared statements, which is kind of a huge deal. Have I missed anything else?
OWASP maintains a list of the Top 10 Most Critical Web Application Security Risks (warning, PDF download). This is from 2010, but I think it still applies, perhaps even moreso now.
Injection and XSS are the top two, but you should certainly be aware of the other 8. If you are using an existing CMS, many of these may already be considered, but the more popular the CMS the more you risk running into vulnerabilities because of black hats trying to find holes in it.
If you are not storing critical data like credit cards, order history, addresses, and even emails, then I wouldn't worry too much about your site being affected as long as you are taking the basic precautionary measures (and it sounds like you are).
If you are concerned about security issues, a good resource is the OWASP - Top 10 Application Security Risks
The most important thing to take care in web applications(specially PHPs') is Data Validation of all the inputs taken from the user which are further saved in your database.
For a secure application, all the transactions should be done on HTTPS. For a secure cookie management Secure and HTTPOnly cookie should be implemented.
Some more points I don't see mentioned yet. Most of these are not related to code - I am not sure if you only wished for things related to code, but I'll mention them anyway.
Backups (user data). should be self-evident
Version control. If you have a big bug, you want to have access to the previous version.
Audit trail, alarms and logging. If you do get into trouble, how will you find out? Are you able to track down what happened? if you know something is wrong but don't fully know what, are you able to diagnoze the issue?
Hosting. Where are you hosting? Do you have adequade bandwidth and monitoring? What happens if you get DOSed? Are you able to block out unwanted traffic?
Caching. Can you change it if needed?
There's always one thing left. Availability :) There are three aspects of security:
Confidentiality (Noone can read what they don't have access to)
Integrity (Noone can change any data what they should have to and you have to be able to detect if it happened even so)
Availability (The data, application whatever has to be available)
You pretty much did a nice job and took care of the first two (credentials, prepared statements, htmlentities...) but none of them will help against a DoS attack. You should be able to detect if someone slaps your site and ban the attackers ip from your server. Although this can be done in PHP (still much better to kick the attacker at the first line of php than let them initialize the framework, database connections etv.) it can be done mre effectively in lower layers (for example: nginx/apache, iptables, snort).
However what you're asking for that usually comes to the matter of risk management. In a real application you're not able to be prepared for all the possible attacks, edge cases etc. What you need to do is classify all the risks by the probability and the impact ( http://www.jiscinfonet.ac.uk/InfoKits/infokit-related-files/Resources/Images/risk-matrix ). With this you can focus on the most important (highest) risks first and probably you can completely ignore the lower bottom part.
SQL Injection and XSS are the most prominent Hacking methods.
You are covered from SQL Injections if you use prepared statements.
Also, if htmlentities() on everywhere you display HTML you should be safe.
i started learning a bit about mysql and while i was reading i was thinking that the security vulnerabilities on mysql are pretty immense and can't be well covered if someone doesn't truly understand pretty much everything about mysql.
if i have a website that will store not a very big volume of information, would it be bad to store it in .php files?
what are the implications and vulnerabilities of this?
it seems to me that the risk is far smaller because if the .php file doesn't have an echo statement, if you try to access it all you get is a blank page, and if you are unable to 'send code' by user input and send files to the website it should be secure as far as the website is concerned (obviously that if the server itself is hacked the attacker pretty much has the control of everything but that's not the point on this matter)
update to the question.
it seems that what i've written above isn't producing the kind of answers that i expect and so i will try to simplify.
what i'm looking for here is why are databases more secure than flat files without bias because most people i've read stuff about on this subject will just say databases are more secure but can't say why. yes they're faster and it's easier to manipulate the data especially if it's complex or with multiple users and there is a lot of info. about that and it's easy to understand why.
the fact is that when i started reading about mysql a few days ago i saw that if your php is compromised most likely so are the databases so writing good secure php code is probably the first and most important line of defense to your mysql databases.
if your php is uncompromised so is the information you stored in php files so if you write good secure php, the security of plain php files will be good.
having databases also makes you use php functions that usually you wouldn't use and some of them possess real security holes that have to be "patched up" so writing good secure php code to work with databases is more complex than writing equally secure code to work with plain files.
also when you have apache/php/mysql installed you have 3 things that may have entry points for hackers if they're not correctly configured and maintained, if you cut mysql loose you only have 2, you won't have to bother with sql injection for example because with no databases that's impossible to happen, you may inject all sql you want but you will get nothing.
so for managing small amounts of data, plain files seem to me like a secure, a bit more complicated to work with the data, slower but not relevant considering that it's a small amount of data we are talking about.
why may these deductions be wrong is the information i'm looking for with this.
Apples and oranges.
You can go to a drag race with a Hummer and complete the race but you will surely be in last compared to a Bugatti. Take a Bugatti off-road and it will definitely fall behind the Hummer.
PHP is a server side scripting language. Data storage and retrieval is not the primary consideration in PHP.
mySQL is a relational database management system. It's design is 100% purposed for data storage, retrieval, and security.
What's your plan for data storage and retrieval in PHP? It seems like will have to do a lot of unnecessary work re-inventing the wheel to achieve this. Why would you?
Without understanding what security concerns you are specifically worried about in mySQL there isn't much more to add.
Edit: An article calling out the general differences.
These two points will cover most security issues:
1)Learn PDO and the prepared statement protocol. This will take care of most if not all SQL injection issues. Do not send raw SQL to a database.
2)Sanitize all your GET and POST data that comes into PHP. This will take care of most XSS.
Many frameworks in other languages do this for you, but the PHP newbie will just use bare PHP and open himself up to all kinds of attacks. That is why PHP is "unsafe."
Read up on security, and try to implement some of the pointers that you feel are important. No language, framework, platform, etc is 100% secure. Just like everything else in life, you take as many steps as possible to minimize the risk.
I'm a PHP/MySQL noob who knows nothing about online security.
Could you point me to some resources that will aid in my knowledge? (Beginner level, please!)
I'll suggest two things:
Make sure Register_globals is off.
Use prepared statements.
This question is well-answered and covers MySQL injection attacks (one of the more common concerns.
This question is also well documented and covers XSS (cross site scripting) attacks well.
Lastly, learn about PHP.INI and how to set it up and what is actually open/closed and on/off. A good host will, for example, never turn on register globals, but you should at least know what it is and why to check it. PHP Security has resources on that and many other PHP security concerns.
PHP might not be the best start. Especially if you're largely hand-rolling your own code. It doesn't exactly hold your hand with security issues. (fd: I wish PHP would go away for a variety of reasons.)
But some general rules:
Don't trust anything that comes from the outside. Always assume the user is some jerk trying to break your app. Most of them won't be, of course, but there will eventually be one who is. Just because you gave the browser a <select> containing a, b, and c doesn't mean you'll get one of those back. Javascript isn't a guarantee of anything. Referers can be easily faked. POST data can be easily faked. Textboxes can contain any character, not just the ones you expect.
Don't copy-paste others' code into production if you aren't sure how it works. You have no idea how much of an eye the author has for security. In my experience, PHP copypasta in particular seems to be less reliable but more frequently blindly reused.
Don't trust yourself to perform the same ritual in dozens of different places. Yes, mysql_real_escape_string() will fix SQL injection, but then you have to remember to use it everywhere. This creates a lot of places where you might make a mistake and forget your escaping ritual. Use prepared statements instead, and the problem vanishes entirely. Another example: Pylons (a Python framework) rigs its templates so any variable is HTML-escaped unless you explicitly ask otherwise. XSS is no longer a problem, and I never have to worry about manually escaping everything I print.
Chris Shiflett is the go-to guy on PHP programming and security:
http://phpsecurity.org/ for his book "Essential PHP Security"
http://shiflett.org/ for his website, blog, etc.
He is Speaking at PHP CodeWorks in Sept/Oct.
If you have some time, you could take a look at the slides used by Stefan Esser during his conference at the Dutch PHP Conference a few months ago, which title was "PHP Security Crash Course for beginners".
There are a couple of PDF :
Part I - Introduction
Part II - XSS
Part III -CSRF
Part IV - SQL Security
Part V - Session Management Security
Part VI + VII - PHP Code Inclusion and PHP Code Evaluation
Those could be helpful.
Then, don't hesitate to search a bit for non-PHP-specific informations : some security problems (like XSS, SQL Injections, CSRF, ...) are not specific to PHP : only the technical means to avoid them are specific ; so, you could find plenty of informations on sites like Wikipedia, or the OWASP website
I just starting out learning PHP, I've been developing web apps in ASP.Net for a long time. I was wondering if there are any PHP specific security mistakes that I should be looking out for.
So, my question is what are the top security tips that every PHP developer should know?
Please keep it to one tip per answer so people can vote up/down effectively.
(In no particular order)
Always check that register globals are OFF
Always check that magic quotes are OFF
Make sure you understand SQL injection attacks
Turn OFF error reporting in production
EDIT: For the "newbies" out there this is a basic why (and since I have time to explain this):
Register globals is an aberration. It's the ultimate security hole ever. For example, if register_globals is on, the url http://www.yourdomain.com/foo.php?isAdmin=1 will declare $isAdmin as a global variable with no code required. I don't know why this "feature" has made it's way to PHP, but the people behind this should have the following tattooed on their forehead: "I invented PHP Register Globals" so we can flee them like pest when we see them!
Magic quotes is another dumb idea that has made it's way to PHP. Basically, when ON PHP will escape quotes automatically (' become \' and " become \") to help with SQL injection attacks. The concept is not bad (help avoid injection attacks), but escaping all GET, POST and COOKIE values make your code so much complex (for example, have to unescape everytime when displaying and data). Plus if one day you switch this setting OFF without doing any change to your code, all your code and/or data is broken and (even more) vulnerable to injection attacks (yes even when ON you are vulnerable).
Your databse data is your most valuable thing on your site. You don't want people to mess with it, so protect yourself and read things about it and code with this in mind.
Again this can lead to security concerns. The error message can give hints to hackes on how your code works. Also these messages don't mean anything to your visitors, so why show them?
Avoid using register_globals.
Warning: This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.
Cross Site Scripting (XSS) Wiki, Google
Cross Site Request Forgery (XSRF/CSRF) Wiki, Google (thanks Rook)
Session Fixation Wiki, Google
SQL Injection (SQLi) Wiki, Google
Turn off error messages in Production environments
Keep any "include" code in a directory that is not web-accessible (either deny access or keep it outside of the webroot)
Here's an article I wrote about storing passwords in a secure way, and if you don't feel like taking my word for it, check the links at the bottom.
Also linked in my article, but given its own separate link here, is a paper published by M.I.T. called The DOs and DON'Ts of Client Authentication on the Web [PDF]. While some of its info (recommendation to use MD5 hash, for one) is somewhat out of date simply because of what-we-know-now versus what-we-knew-then, the overall principles are very strong and should be considered.
One of Rooks' links reminded me of another important set of restrictions
Turn off Register Globals (This is the default now, so I hadn't mentioned it before)
When dealing with file uploads, be sure to use is_uploaded_file() to validate that a file was uploaded and move_uploaded_file() instead of copy() or rename().
Read this section of the PHP Manual if you need to know why (and you do).
Since I've now mentioned him twice, check out Rooks's Answer (https://stackoverflow.com/questions/2275771/what-are-the-most-important-safety-precautions-that-a-php-developer-needs-to-know#2275788) as it includes a link to a document which contains (Non-PHP-Specific) information on the most important security concerns (and this therefore probably the right answer).
here is a link of good PHP security programming practices.
http://phpsec.org/
Most of the security issues revolve around user input (naturally) and making sure they don't screw you over. Always make sure you validate your input.
http://htmlfixit.com/cgi-tutes/tutorial_PHP_Security_Issues.php
Always sanitize and validate data passed from the page
In conjunction with #1, always properly escape your output
Always turn display_errors off in production
If using a DB backend use a driver that supports/emulates prepared statements and use without prejudice :-)
don't use "Register Global Variables" and filter user input for xss and injections
Language Vs Programmer. You can write the most serious vulnerability and you won't get a warning or error message. Vulnerabilities can be as simple as adding or removing 2 characters in your code. There are hundreds of different types of vulnerabilities that affect PHP applications. Most people think of XSS and Sql Injection because they are the most popular.
Read the OWASP top 10.
If you're using a mysql database make sure you call mysql_real_escape_string when sending data to the database
There are tons of safety precautions. I can recommend a book Chris Shiflett: PHP and Web Application Security.
http://phpsecurity.org/
Have a look at the Suhosin Hardening Patch, and check out the security vulnerabilities that it addresses.
The PHPSec Guide gives a good overview.
Most of the security issues related to PHP come from using unparsed "outside" (GET/POST/COOKIE) variables. People put that kind of data directly into file paths or sql queries, resulting in file leakage or sql injections.
OWASP provides a lot of insight into security issues that are the biggest problems in applications today. It is nice to see that they have a PHP dedicated page available
http://www.owasp.org/index.php/PHP_Top_5
Always Close you SQL Connection.
Always Release SQL results.
Always Scrub all variables your putting into a database.
When deleteing or dropping from sql use limit 1 just in case.
When developing make sure you have a lock on things to keep the undesirable out. If its open and you know not to load the page right now because it could break something, doesn't mean other people do.
Never use Admin or Root as your server log in name.
Whenever possible, use prepared statements (tutorial. It's almost a must whenever dealing with user input (I say "almost" because there are a few use cases where they don't work), and even when not dealing with input, they keep you in the habit. Not to mention they can lead to better performance, and are a LOT easier, once you get into the swing of things, than piecemeal sanitizing.
Often introductory tutorials don't talk at all about checking data from users. Like all programming environments, never trust the data you get from users. Learn to use functions like is_numeric(), isset(), and mysql_real_escape_string() to protect your system.
There are also features that allow you to access remote files, and other creative things. I'd avoid those until you have a good understand of how and when they work (often they are disabled for security reasons).
Use POST method for data passing from one page to another.
Use trim while getting data like trim($_POST).
Also, use strip_tags for variables before you passing into the queries.
I am suggesting you use any framework link Codeigniter, Laravel, YII, Cake PHP because they maid framework with all securities
I suggest Codeigniter for small projects and Laravel for big projects.
Always use POST and not GET for important Data...