There are a lot of confused posts in here that don't seem to know some of the basics about exploits and how they work. So I figured that while I'm still in newbie jail I'd help other newbies out and explain some of them: SQLi SQL injection
An SQL injection attack is a server side attack that basically checks to see that input parameters are checked and tries to execute database commands from a browser. As an example if you went to a site and had the following url: http://example.com/trade?id=1
which executed the following sql: SELECT * FROM TRADES WHERE ID = 1 an attacker may change the URL to http://example.com/trade?id=1;SELECT
* FROM USERS, which may throw a database error that leaks some information and may allow an attacker to work their way into a system.
They're bad and trivial to defend against, but unfortunately very common. Sites should be sanitising input and using parameters in queries. Any sites that are vulnerable to them should be avoided, if they can't get this right they've probably got a lot wrong besides. XSS (Cross site scripting)
<script>alert("you've been hacked");</script>
They're bad and trivial to defend against, but unfortunately very common. Websites should sanitise input they're displaying to users to prevent attackers from doing this. Any sites that are vulnerable to them should be avoided, if they can't get this right they've probably got a lot wrong besides. CSRF (Cross site request forgery)
The CSRF doesn't have to come directly from tradegraphs.com either, it could be injected using a XSS above.
The biggest misconception I see about CSRF here and elsewhere is that you have to have the window/tab open on the target site for them to work. THIS IS WRONG!
You just have to be logged in, even if you close the tab or window if your browser is still open you still have a session to that site until it expires. If you've set the site to remember you by setting a cookie it's also as good as open, so you may not have even opened the site in your current session and you're still vulnerable.
Defending against them isn't easy. As far as the target site knows, you're a valid using doing valid user things. There are a couple of strategies depending on the sites and the required security that work though. The first is to introduce nonces (n
umber used once
). For every action a user takes a number is randomly generated, they need to include this nonce when they make their next request or they get thrown out of the site and have to log in again.
This nonce is why you'll often see banking websites break when you click back buttons or try to navigate out of order.
Another way is to include a further form of authentication for actions that require higher security. So called two factor authentication, usually I know something (password) and I have something (bankcard). Many banks require transfers to be authenticated with a chip and pin reader, text message or secondary password. Don't let them fool you though, two passwords is NOT true two factor authentication.