www.notsosecure.com

A number of websites allow users to play flash games online and then submit their score. After the competition end, the user with highest score wins a prize. A major problem which such websites face, is, how do they ensure user submits the correct score?

The scores submitted by user is mostly a HTTP POST request, which the user's browser makes to the web server. This request could easily by modified using a man-in-the-middle(proxy) tool and thus a bogus request could easily be submitted. This is a very common/popular hack for flash games. Unfortunately, there is nothing much a server could do to stop users from submitting bogus scores. A server could make it harder for users to submit bogus scores by encrypting/signing the score. It is to be noted that flash files could easily be decompiled and the hashing algorithm could be obtained and a determined attacker could still submit a bogus score (hashed).

A  very interesting discussion could be read here. I particularly liked these comments:-

"One idea I had would be for the game to keep telling the server it's current state, and the server could employ cheat detection algorithms to detect unlikely events happening in real time - and then stop the game from continuing"

"Comunication between client (flash) and server(php) is going throught XML PRC protocol. This xml rpc protocol is fully crypted. So Flash client send a crypted xml-rpc request, I decrypt it in PHP, and send encrypted response that Flash decrypt for its self. Of course HTTP comunication is transparent..but consist of binary 256bit crypted data. The point is it's gonna be very very difficult for someone to sniff comunication and to 'cheat' it."

If you know a solution to stop a user from submitting a bogus score, do let me know..

A few days ago, i came across this mail fraud. I was looking for some merchandise and came across this forum, in which someone has advertised an iphone for just 100 quid. This sounded very phishy and too good to be true. I decided to contact the person and enquire about the product. The person on the other side of internet, narrated me a story which is also documented on this phising website:-

http://tnteu.com/tnt.express.london.depot.overseas.transactions

What is interesting to note is the tracking option and the website layout. The 'whois' information shows the domain has been recently bought. Also, the homepage of the website redirects to the legitimate website. 

Note:- Please be careful while making a deal with anyone on the internet. Any deals requiring money transaction through untraceable means like Western Union, is more likely to be a scam.

As demonstrated by ferruh 'http://ferruh.mavituna.com/flawed-csrf-protections-oku/', this is a serious flaw which surprisingly went un-noticed. An admin could be easily tricked into clicking a 'Yes' button resulting in a password update. An attacker could also update the admin's email and use the 'forgot password' functionality to reset his password. Wordpress, do not ask user's to provide their existing password to change it.

This demonstrates that inorder to protect against Cross Site request Forgery (XSRF), application's must discard the request whenever any XSRF attempt is detected.  

Consider the following scenarios:-

Scenario:-1. The cookies in browser are set by application which is accessible over SSL (HTTPS). The same website(same domain) offers some functionality over HTTP, which is vulnerable to Cross Site Scripting (XSS). Can, an attacker obtain his cookies?

Case:-1 Cookies are not marked secure by the application, so the browser sends it to http as well, hence, an attacker can obtain them through XSS

Case:-2 Cookies are marked as secure, so the browser does not send them over HTTP, and hence an attacker can't get them through XSS on HTTP site. This answers the question, asked in the title. Secure cookies, are indeed secure.

Scenario:-2 Cookie is set by website over HTTP(cookies not marked secure). The website over HTTPS is vulnerable to xss. Browser will send cookies to the vulnerable website (over SSL). An attacker can gain all cookies associated with this domain name.

Hope this helps. 

I have found it difficult to exploit, xss in 302 HTTP response, primarily because browsers follow the redirect and not execute the XSS.

For a moment, lets visit the attacks session fixation and HTTP response splitting. Consider a scenario, when an attacker is able to inject in the HTTP 302 response header's  'Location:' field. Through CRLF injection, it will be possible to use 'Set-Cookie'  header and set a cookie in victim's browser. This will only be useful when the application is vulnerable to cookie fixation. The attacker can than use the fixed cookies to hijack victim's session.

Checking if the application is vulnerable to cookie fixation, is quite trivial. You supply any expired session-id in cookies to the application along with a valid user-name and password, and if the application revalidates the supplied session-id in cookie (instead of issuing new random session-id), than it becomes vulnerable to cookie fixation. As session fixation is normally associated with URLs using session-id in URLs, this issue could. at times, go unnoticed.