I've been playing with HTML5 location lookups recently and its relatively straightforward to pull someones location from a device like an iPhone.
I want to write an app that uses location data, but its important that the location be factual. In other words I need to prevent people from authoring a fake post to the backing website / web service with mocked up GPS coordinates.
Is there anyway to collect GPS coordinates from a mobile device using the HTML5 geolocation apis and securely transmit that back to a web service in a way that someone wouldn't be able to author a post with the same data and "game the system" so to speak?
Not without some serious encryption on the payload on the client. Which if there is money involved, someone will reverse engineer and figure out how to create valid payloads themselves. Remember if there is money or fame involved then somebody will think the effort to do something like this is "worth it". If your web service is public and not using some kind of encryption nothing on the client will ensure that someone with a network connection can't sniff your protocol and fake whatever data they want. And SSL won't cut it. Anyone can proxy the SSL connection on their local network decrypt the payload and inspect it to their hearts content.
No. Completely agree with the answer from fuzzy lollipop. If you’re talking to a remote machine, the data can always be faked. Always always. What makes you certain you’re even talking to a mobile device at all? The User-Agent string? Pfft, it can be faked. Talking to a GPS? Pfft, could be coming from a predefined path. Talking to a web browser? Pfft, could be a bot, or some other malware.
And don’t think encryption (i.e. HTTPS) is going to help you. The client could edit any of your HTML, CSS, or JavaScript on-the-fly — take Firebug or Greasemonkey for example.
The reasons why you can’t trust the client are the same as the reasons why exploits such as SQL or HTML injection are so common. Ever heard the phrase “the customer is always right”? Well, the customer may be right, but the client is always untrustworthy.
The system is there to be gamed. As flaws are discovered, you patch them one by one. It’s more like leapfrog, rather than achieving the holy grail. Bruce Schneier’s quip “security is a process, not a product” comes to mind. Asking for a system that “can’t be gamed” is missing the point. What you need to be doing is creating a system where the server sanitises the data, and/or rejects bad data — fuzz testing is not a bad idea, either.
That’s about the best you can do without shipping custom untamperable mobiles to your customers with the OS in ROM, and the inside sealed with epoxy.
Related
I'm attempting to make a mail client that is HTML5/JS only where users would have to define their mail server and credentials.
I've surfed google leading to dead ends and figured that this is the next best place (or superuser.com).
I was thinking of using HTML5 WebSocket if I could to make the connection to the server but I don't know enough of smtp, imap, or pop3's architecture to understand how javascript could pass the args and perform what I want it to do.
PHP cannot be involved in this project otherwise I wouldn't be asking the question.
Any help in locating this would be fantastic.
Nothing is impossible. Except this.
In standard HTML or JavaScript, you can't make raw-socket connections, which is what you'd need to speak any of the protocols you've listed. The WebSocket API doesn't help you, because the server must also speak WebSockets, and mail servers don't. This is actually all a good thing, though. Imagine if you visited a random website and it telnetted to your home router, setting it on fire and burning down your house. That's what websites would be able to do if they could initiate plain TCP socket connections.
You have a few options I can think of, neither of which involves building a webpage. (And to be clear, you didn't say your project had to be a webpage; you merely said HTML/JS, so these are indeed legitimate options.)
First is something like node-webkit. As the readme says, "You can write native apps in HTML and Javascript with node-webkit." You'll still have to distribute it as a native app, because that's what it is.
Second is a Chrome app, specifically using the chrome.socket API. But have fun writing a TLS layer over those sockets, which you'll find is a requirement for almost any mail server these days. If you succeed in doing that, you'll be able to distribute your mail client in the Chrome Web Store, where I assure you an email client will be quite popular.
Third, write a webserver that operates locally, so your users will visit something like http://localhost:9999/mail in their browser. This will be a real pain to distribute, but you can use almost any technology you want.
I'm sure there's a fourth valid option, and someone else can chime in on that one.
Best of luck.
We want to build an offline capable HTML5 SPA with sensitive business data.
Most likely with knockout.js!
But we have really hard security concerns.
What about encryption? Encryption may be possible. But the appropriate key has to be on the (offline) client side as well. And if you have both the algorithms plus keys on the client side you could also store it unencrypted in local storage.
What about data manipulation? It´s easy to manipulate the DOM or JavaScript objects with tools like Firebug etc.
I really love knockout but it doesn´t feel right for real world business applications.
Any suggestions?
I'm no security expert, but if you use js to encrypt/decrypt client-sde wouldn't you have to store both public and private keys client-side? Effectively neutralizing your whole security model.
I think once you have data client-side there really is no way to keep it fully secure, you have to trust the browser to keep the state private but really to be 100% secure you either have to abandon the web or live with the consequences by redirecting to a page or destroying your state after specific time period, sending partial data to the client and relying on server side to fill in the blanks. In a sense all web pages are offline capable if you don't close the tab. Think of your banking website with all your account activity on the page, I see no distinction between that and offline js from a security point of view.
Re: Data manipulation, this really isn't a KO "feature" but JS allows you to do pretty advanced data manipulation and libraries like linq.js make things so much easier. Not quite sql but respectable none the less.
I think KO is absolutely right for real-world business applications. More broadly the browser/js/html may not be right for the level of security you are after.
Bit of a rant, Hope this helps.
Over the years I've become an uber-nerd when it comes to flash game development. Now I'm thinking about looking into using my skills for helping other game-developers out there.
I want to develop an API in AS3 which will allow the developer to do (as a start) the following:
Display a dialogue which lets the user log into their "account" (hosted on my site).
Send a score/value to the website and attribute it to the logged in user.
Unlock an achievement (achievements will be set up by the developer in the web interface - which is where they will also get a key of some type to use with their API.
Display high scores, other players profiles in-game, etc (show basically any stats in-game).
All easy enough to develop straight off the bat. However; where it becomes frustrating is security. I'm not expecting an indestructible solution that I'm fully aware isn't possible, but what would be the most defensive way to approach this?
Here are the issues that I can think up on the spot:
The big one - people stealing the API key via man-in-the-middle attack.
Highscore injection, false achievement unlocks.
Decompiling the SWF and stealing the API key.
Using the API key to create a dummy flash application and send random data like highscores.
Altering the API itself so you don't need to be logged in, etc.
One thought I've had was converting my API to a component so there's no access to the code (unless you decompile). The problem here is it's just not friendly to the developers, though it would allow me to create my own graphics for the UI (rather than coding many, many sprites).
Private/public keys won't work unless there is very good protection against decompiling.
I'm beginning to wonder if this idea is a dead end.
Any advice on securing this (or parts of it) would be great.
Look at this thread first if you haven't done so already: What is the best way to stop people hacking the PHP-based highscore table of a Flash game
Against man-in-the-middle HTTPS seems the only option. It may have its vulnerabilities, but it's way better than any home-made solution. The problem that you'll need actual certificate from authorized center, because ActiveX-based Flash plugin will not trust self-signed certificate.
Should not be possible without decompilation
SecureSWF with reasonably high settings (code execution path obfuscation and encrypted strings) should beat most decompilers. Sure, SWF can be examined with hex editor, but this will require very determined hacker.
Should not be possible without decompilation
API should be on server and any API function would require user context (loaded by HTTPS)
Also add encryption to flash shared objects\cookies. I had successfully altered some savegames using simple hex editor, because they were just objects in AMF format. Encryption will depend on SWF decompilation, but since we are using SecureSWF... Or move savegames on server.
client side is never secure enough, so i'd suggest to take all the logic to the server, reducing client to just UI.
If it's impossible due to network timeouts - send scores/achievements only with the log of pairs "user_action - game_state" and verify it on the server.
I really need your help with this. We are planning on developing a real-time web application. We look at different libraries and concepts and a little confused.
What we need is: clients connect to websites and send data(usually an integer + client machine name) whenever they want (usually 1-5 seconds). Also, the same clients must receive data(the data received from other clients) from the server in a real-time mode. (maximum 0.5 seconds). Also, this data must be stored in the database.
We were thinking about using different technologies, but cannot decide which one to use.
We need this web application to be supported on Iphones and Android Phones (maybe blackberry).
and, of course desktop browsers.
Pooling seems not a very good Idea in this situation, due to highloads.
Html 5 web sockets kinda new, and probably not supported by all browsers.
Have anyone used nodejs ?
or twisted matrix: http://twistedmatrix.com/trac/?
or orbited(cannot post more than one link)?
or tornado?
Or XMPP(Jabber. I did not find good examples.)?
or something else?
What technology is the best to use in this type of project? Also, we would probably prefer the technology that has some community support and free to use.
Thanks a lot!
There is a lot of things to consider here. I would say that HTML 5 is not an option, simply due to support across platform.
Running with NodeJS is most likely possible, but the communication methods are really complicated. Pushing data to a page isn't really something that HTML/web apps are designed to do....
To get a valid answer you are going to need to get someone to come in and sit with you to really iron out details and implementation.
When you say that clients "connect to a website", do you really need it to be a website? It sounds like all the client is sending is a number and for that you don't need a website. Just pick the language of your choice, open up a socket, and go from there.
Are you streaming data to be visualized? You might want to take a look at graphite (and/or "pyped" which is part of graphite).
What kind of data? What is the purpose?
For real-time you're not going to get a web site unless you use some type of RIA but even then, it isn't going to be enough. Services aren't going to be good enough either. You're going to end up doing some type of polling which will only ever be psuedo-real-time unless you do duplex mode which wont be supported on most of the platforms you want to support.
sockets are the way to go but that requires a client for each platform you want to handle. Maybe you should rethink your requirements.
I want to implement a discrete remote authentication server that handles login for many sites. Somewhat similar to OpenID.
Basically, I have site-1 and site-2 and they're both reliant on the same user database, which is on a separate auth-site. So, auth-site handles user authentication for them, and during this process, makes information on the authenticating user available to the requesting system.
Each site can be on a completely separate domain name, on completely separate machines.
This is all via HTTP(S), there can be no direct database access.
There's one last quirk: once an user has logged in to site-1, when accessing any other site reliant on auth-site, the site must treat the user as already authenticated.
This whole business must be entirely fuss-free to the end-user. It should work like a simple everyday login form.
As a concrete example, say we're talking about stackoverflow.com and serverfault.com, and they both authenticate via authentic-overflow-server-stack.com. Again, once logged in to either site, I can go to the other and do my business without logging in again.
What I'd like to know are the general interaction mechanism between the sites behind this scenario.
In my particular setup, I'm using Rails, but I'm not looking for code[1], just general best practice and guidance, so feel free to answer in pseudo-code or any generally readable language. OTOH, bear in mind that I'll have decent MVC, REST, and meta-programming in my toolkit.
[1]: unless you happen to know an existing tiny neat free MIT/BSD-licensed app/plugin/generator that handles this.
It sounds like (especially with the emphasis on fuss-free), you want something like what the Wikimedia Foundation is doing. Basically, you log on to en.wikipedia.org, then that server communicates with other servers (e.g. en.wikinews.org) and gets authentication tokens. Finally, those tokens are embedded into images, e.g. http://en.wikinews.org/wiki/Special:AutoLogin?token=xxxxxxxxxxxxxxx , and when your browser visits that url (img src) it gets a authentication cookie for Wikinews. Of course, the source code is available for your reivew at http://www.mediawiki.org/wiki/Extension:CentralAuth .
OpenID is also a good choice, but it does require that the user "consciously" visit two domains. An example of one entity with two domains doing this is Canonical. E.g., if you go to https://help.ubuntu.com/community/UserPreferences they will redirect you to Launchpad (https://login.launchpad.net/+openid) for authentication.
Note that Wikipedia is doing this over http, but you can do it all https to ensure the img src tokens aren't intercepted.
Looks like CAS is good enough for me, and has ruby implementations, along with dozens of other lesser languages, e.g. one that rhymes with femoral bone rage.
http://code.google.com/p/rubycas-server/
http://code.google.com/p/rubycas-client/
It sounds like you want to actually use the OpenID protocol itself. There's no reason you can't restrict the authentication provider to only your own server, and do some shortcuts that make the authentication process transparent. Also, the OpenID protocol supports what you describe about logging into one implies logging in to all services.