99% of forum img tags are exploitable to a form of XSS. You can run a PHP script from a different site in the users browser inside an img tag.
so instead of putting a .jpg put the link to a script and it will run
Topic: About exploits (Read 783 times)
good post myrm. thanks!
Nothing really. There seem to be a lot of people posting about how it would be impossible for them to have been a target of a CSRF because they'd closed tabs and other confusion related to what the exploits actually are and how they work; Lots of people seem to mix up XSS and CSRF for example.
Just thought some people may find it useful.
Just thought some people may find it useful.
Um, what exactly are you trying to achieve by posting this here?
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)
A cross site scripting attack is when someone injects Javascript into the site you're working with that does something it shouldn't. Basically you craft a some javascript in a field you control and you can access it. Things like forum posts or even usernames could have javascript in them which downloads a file from another server and it will be executed by your browser as if it was part of the page.
I've seen these work in some pretty funny ways - some of the sms numbers you text will just blindly interpret javascript for example so if you send:
Obviously you can do other things with this, like execute trades or transfers because your session is open and the javascript is executing as if it was you.
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)
A cross site request forgery is similar to the XSS above except you don't inject the code into the current site, you inject it into another site. Let's say for example I'm trading on tradesiteA.com, tradesiteB.com and looking at a pretty graph on tradegraphs.com. Now let's say that tradegraphs.com isn't all it's billed to be, they quietly put some javascript on their page that in the background accesses tradesiteA or tradesiteB and does things on my behalf. It works just like Ajax calls, you'll never see the requests or the results until you realise your account has been emptied.
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 (number 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.
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)
A cross site scripting attack is when someone injects Javascript into the site you're working with that does something it shouldn't. Basically you craft a some javascript in a field you control and you can access it. Things like forum posts or even usernames could have javascript in them which downloads a file from another server and it will be executed by your browser as if it was part of the page.
I've seen these work in some pretty funny ways - some of the sms numbers you text will just blindly interpret javascript for example so if you send:
Code:
to the number the admin will get a javascript alertbox when they view the message. I had a friend do this in a pub while he was taking a piss and got panicked calls from the company the next day.
Obviously you can do other things with this, like execute trades or transfers because your session is open and the javascript is executing as if it was you.
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)
A cross site request forgery is similar to the XSS above except you don't inject the code into the current site, you inject it into another site. Let's say for example I'm trading on tradesiteA.com, tradesiteB.com and looking at a pretty graph on tradegraphs.com. Now let's say that tradegraphs.com isn't all it's billed to be, they quietly put some javascript on their page that in the background accesses tradesiteA or tradesiteB and does things on my behalf. It works just like Ajax calls, you'll never see the requests or the results until you realise your account has been emptied.
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 (number 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.
Jump to: