I am an iOS developer & developed a web services app which has been live on App Store for a year. Now I decided to make this app available cross-platform - beginning with Android, for which I hired an Android Developer.
Until this hire, all the web related code & data (PHP / MySQL / XML) was managed & fetched by me alone - so I did not worry much about the security. But now, with addition of another developer I have following concern:
The app sends POST request which includes how many rows to fetch - then a PHP script gets that many rows from MySQL & returns them in a well formatted XML. My concern is that now the employee will also know about the whole process & although he will not have direct access to PHP scripts OR MySQL database, he can still misuse it in a number of ways. For example, he can create a URL on web browser with a POST request for 100000 rows even - which will let him have all the data in an XML.
What measures should be taken to counter this? (Yes, I can force a hard limit of 40 in above particular case, but it is not an ideal or generalized solution.)
BTW, I did an extensive google research on this topic & to my understanding, the above problem is known as "Semantic URL attack". But I was not able to figure out the right solution for it. Using "Sessions" is suggested, but according to my understanding "Sessions" is only helpful if we have password based user authentication - which is not the feature of my app.
Any help would be highly appreciated.
First you must be aware that if you have no protection and allow just anything, people will be able to do anything, as simple as that. So as I understand, you don't want to use the standard protections: i.e. users having login credentials, and using per-case defensive programming.
Okay, then one partial solution would be to compute a hash:
you want to query the server with the parameters P
you compute H=hash(P)
you send ?p=P&h=H to the server
your server receives ?p=P&h=H and computes H'=hash(P)
if H' != H, then the server denies an answer
You would have to compute the same deterministic hash function in php and in your mobile app, preferably a very complex one, mixing your own dark encrypting algorithms with md5, sha1, synchronized threads, etc.
If you worry about the attacker to repeat an old query with the right hash, you can make a more complex handshake: first send to the client a random number, which will be a part of the hash to compute. Or something based on the datetime, the ip, or whatever.
Of course if the attacker reverse engineers your code, he can find out the hash function, but it would take him some work at least. You can obfuscate your client's code if you want to make his job harder.
As a testimony, I have used this sort of technique against lame attackers on services which didn't require a registration. Unless the attacker is a pro and badly wants your private data, it works.
Related
Hi I was wondering if it's possible to make sure only a specific device can validate a QR code?
For example I have a e ticket with a QR code. The QR code is going to be used to check people in to a specific ship they are going to board. Workers have a certain device which they can scan the QR codes with. This device only may validate these QR codes.
The reason I'm asking is that we don't want random users with random smartphones to scan the QR codes and trigger a URL that does the check-in and control when they aren't there and the date is not the date of the ticket and is not the device that should have validate the QR code.
I have no idea if there is a way to send a devices unique number along with the QR code or that the code on the specific URL can read out the information of the device ?
We are using PHP to create this web system. Has anybody done something like this before or does know how to deal with this issue ?
Looking forward on some information since I haven't found any useful information regarding issue's like these.
TL;DR: at its core, the issue isn't with QR codes, but rather with a severe design flaw in your application.
QR codes are standardized and meant to be somewhat ubiquitous. It's their ubiquity that has driven users' familiarity with them (how they look, what they do, how they can use them) and, thus, their adoption. There is no widely-available QR code standard that includes provisions for white-listing only certain devices to scan the resulting image. Even if there was, there would be numerous problems with this approach:
QR codes are somewhat permanent - they are usually affixed somewhere in the real world. If information about which devices were allowed to scan it could be embedded in the QR code itself, what would happen if you wanted to authorize a new device? It'd be financially and temporally impractical to replace every last QR just to allow this one new device.
QR codes can only store a finite amount of data - dependent on how many devices you'd actually want to be "authorized" to use a code, the authorization information could fill to a maximum capacity quite quickly.
Both the bullets above are a bit moot, as QR codes are evaluated by the scanning device - it would be somewhat trivial to patch over and bypass these restrictions on almost any device (similar to how you would never fully trust a validation happening on a client, and verify the data received on the server side).
It seems like you're trying to solve what appears to be a design flaw in your application by seeking to arbitrarily modify this widely-used standard to meet your specific use case.
Possible mitigations
Continue using a QR code tied to a specific URL, but only allow requests to change data/state when authenticated. Have your users navigate their mobile browser to the application in question and authenticate such that subsequent requests to the application (opening the URLs with the QRs) will be authorized correctly, and those without a valid authorization are greeted with a lovely 401 Unauthorized.
(It's somewhat concerning that you've implied both that (a) the state changes triggered by accessing these URLs are somewhat sensitive (in that you don't want random people scanning them), and (b) there's not already any system of authentication to prevent anyone, by either scanning the code or simply guessing the URL, from modifying this sensitive data on your server. I'd strongly suggest reviewing this design with someone from a security perspective to mitigate these risks before your data is tampered with by a third party.)
Change the design so the QR code being scanned is simply arbitrary textual data - similar to that of the numerical encoding accomplished with UPC barcodes - and have the authorized users leverage a custom client application that can take that arbitrary data and generate the proper API calls/URL opening(s) in the background.
Write your own standard similar to QR codes, and a corresponding client application to consume them.
As with most "is it possible?"-esque questions, the answer is usually "yes", and the variables are moreso things like time, funding, and knowledge (among others). It's unlikely in most all cases that you'd have a team with enough of all three to be able to pull this off in a reliable and secure manner, but if you did, your researchers might be able to write something completely new that could integrate this "authorization" as you wish to design it.
However, they'd still have to overcome the shortcomings I mentioned in my bullet points above for this to work, which would require supremely novel approaches to the problem usually only found in academic sectors and organizations with "skunkworks"-type departments. (Read: this is probably not what you want to do).
All in all, when using QR codes like this, the onus of security will be entirely on the receiving server/application. There is nothing in the QR code standard that will perform this authorization/authentication layer for you.
Aside from the three mitigations here, I'd also encourage you to take an even further step back to really evaluate whether QR codes are even the appropriate tool for this task.
I am planning on making a game with actionscript 3.0 (flash). However, I am having some security issues on saving user points.
To be more specific, read below and you'll understand what's the exact problem.
You are starting my flash application. PHP creates a session for your username. Playing for few minutes and reaching 750 points.
You click on "Save my points" button.
It connects "game.php?points=[]" with your point amount, hence, game.php?points=750.
PHP connects to MySQL and does an update/insert query with the username you entered when opening application, and gets the points with $_GET['points'] as you can see on 3.
The issue is,
Anyone who could directly browse "game.php?points=999999999999" would have his points saved in the database.
I thought about encrypting the points, however, Flash is a client-side application and anyone could change the "points" value with an application like "Cheat Engine". Once they change the points, encrypted points will automatically be generated by Flash.
I also thought about creating a private key for each player on their signup and encrypt accordingly, but it also won't work because once an user change his points with Cheat Engine, flash will automatically encrypt the points with given private key, hence, another useless theory...
Some people suggested me to use SSL, just because popular companies like Zynga uses it, but I am looking for other theories here.
Any ideas on this case, except using SSL?
Ps. The game will be a MMO, so securing data transaction is an essential.
For a real secure approach you need to move your game's logic to the server as much as possible and ideally make the flash movie just an interface to show the game's current state to the user.
Check out Yeldarb's post in this thread for a good explanation.
First of all SSL doesn't help you at all. It sounds like you have never heard of Tamperdata.
This is a classic CWE-602 violation. Cryptography does not address these problems because the attacker has more control over the application than you do. There is no place to hide a secret.
I'm making a simple game with Java / .net as client and using php webserver.
Now when someone finishes the level, quit or starts a new game the client sends information on a php Page that stores them in a mysql database.
Now i wouldnt that the users cheat.
To use the game client you need a username and password.
The client sends the number of times that they played the game, which player has defeated, how much points earned. So if i send clear information someone with a sniffer could see which php page I call and copy the information a send to the webserver.
So what's the best security/check system in this case?
I was thinking about use any crypt system that i usable in java vb.net c# and php (like des , md5) but I would like to know if this is the better solution or not.
Update The clients dont use The Web Browser to comunicate with the WebServer. It's WinForm application for example that call php pages to get information and to update data on Mysql DB
Thanks a lot
Some things you should know before continuing:
Everything that is on the client browser can be inspected. This includes all calls you make back to your database server. Encryption doesn't matter for this because, obviously, your javascript code will be the part encrypting/decrypting the data. Javascript can easily be looked at to get the keys.
Even Flash etc can be decompiled by those willing to spend the few minutes working it out.
Don't wait until they have completed all of their games to send info to your database. Do so as the actions occur.
You can only make it a little hard, not impossible, to cheat when using javascript as the game engine in your browser. By "a little hard" I mean it might take an hour for someone with even halfway decent programming skills to defeat... most likely much less.
Regarding sniffers. It doesn't matter if your site is SSL enabled or not. This only protects the information once it leaves the computer. It is not going to do anything about a sniffer located on the client machine.
To sum up: your only real defense here is to make cheating something that is not worth anyone's time to do.
The best option would be to have the application use a webservice and the Client application encrypts the message before sending, but unless you put in some aditional salted data (such as a timestamp to try and mitigate any replay attacks) then you'll still be open to people being able to 'easily' cheat.
.Net has some good WCF service options, and although I've never used WCF with a php endpoint the idea of WCF is to allow cross technology communication, the best bet would be to do some research into that field.
Also to note, MD5 is not an encryption method, it's a Hashing algorithm, meaning that once the data is hashed it can't be recovered.
I am currently building a Flex 4 web app using PHP as my backend. I am using AMF to let the backend and flex application talk to each other.
How can I protect my AMF endpoint? Users can just decompile my flex application, find the URI to my endpoint and call methods. I need to ensure that all calls to the endpoint is done from within my application.
I would like to prevent somethig like this from happening: http://musicmachinery.com/2009/04/15/inside-the-precision-hack/
What are the best ways to achieve that?
Thanks :)
URLs aren't important. They're very easy to find out from any web application, and yet you still need it to have public access to them. There are a few things to do, first, if you're interested in the data security itself, you'll probably want to have your server running over https instead of http. If data security isn't crucial however (and it often isn't), you just need to have a quick and dirty authentication system.
I'm sure you can find many articles online or even frameworks made for authentication for php. In the past when I needed a very simple authentication, I would have my client send over a username and SHA1 password to an open authentication function on php, which would then create, store and return a session ID. That session ID would then be the first parameter of all the other php functions. Those functions would check the DB to see if the session ID is there or still valid (15 minute timestamp from the last time it was used) and if it is, go ahead with the function.
This is just a very simplistic way of doing things and will be good for a lot of small websites. If you need more security, send all of this over https to prevent sniffers to get the session id sent over the wire. After that, you're going into enterprise security which is probably overkill for what you want to do and will cost you an arm, a leg and your left testicle :P
I wrote a game in c++ using SDL. The game currently updates a highscore to my game site by making a post with curl if the user has logged in. The problem that I am having is that the post provides the url to the php file that receives the post on my server, and the variables that the post uses. Last night someone from china figured this out and created 5 accounts and then posted ridiculously high highscores to those users. Is there any way I can make this more secure?
Would ssl work? I've been reading about ssl all morning, and I got curl to verify that ssl is installed, but I honestly dont even know where to start with getting my php verification page communicating with my game using ssl. I'd really hate to take the whole hiscore feature down because I've already invested so much time into all of this.
At this point I am looking for the simplest solution to prevent someone from making a form and posting new hiscores to the php page.
Any help would be greatly appreciated.
You could add a small layer of security by passing not only the high score, but a hashed version that is validated on the PHP side.
e.g.
{hs:"2000";hash:'843ed7842a6bd864162022e48b84a668'}
Posted to your PHP script, that then checks,
if($hash==md5('secret'.$hs)){
//UPDATE HighScore
}else{
//Discard, flag spammer
}
The quickest solution would be to keep an eye on the high score list, delete impossible-looking scores, and blacklist known cheaters.
However, for a longer-term solution, could you possibly send a list of the players' timestamped "physical input" (mouse clicks, key presses, etc.) along with the high score?
The server could then perform some logic using the input (perhaps even running that input through a game client running on the server) to determine whether the high score is valid.
If your game uses random numbers, you'd have to send the initial random seed as well.
Once you manage to implement this, you could fairly easily create a replay system, too, which would allow players to share replays of their games with each other.
You can add salt to data, and only app on c++ knows it, and server
Or you can`t?
SSL itself won't be enough to stop people from posting high scores. There are a couple approaches I can think of to begin with:
Ship your code with a secret key that is used to encrypt the high score before sending it to the server. This has the downside that someone could reverse engineer your game to get the key. This is probably okay though, if you don't think someone would go through the trouble. Crypto++ is a C++ encryption library that you could use for this. You probably want to use symmetric-key encryption.
What I think some other games do is to use some aspect of the game along with just the raw high score value to make a submitted score invalid if it didn't contain the game state.