I've got a big project ahead of me, basically it's going to be a online, kind of hazard game, something like poker. My problem is, that I'm not really sure what would be the best way to approach the client side.
Because the game will involve real money, security is going to be a big issue. For the server side, I don't think it will make a lot of difference what I choose, since all the communication will be encrypted, but I'm more worried about the client.
From my experience working with Java, there are quite a few decompilers, and bytecode probably isn't that hard to crack (am I wrong here).
Since the game will require some 2d graphics, I'd like to work with a technology that makes GUI development at least a little bit smooth.
My other thought was about Flash, but since I haven't seen many online casinos use Flash, it might be a little bit more vulnerable than Java/.NET?
What I'm trying to ask here is, what technology would you recommend to develop a very secure, client side GUI application with some fancy 2d graphics?
In my opinion, there is no such thing as a secure client. No matter what you do, someone will decompile/reverse engineer it-- especially when there is real money involved. If I were you, I'd concentrate on making the server secure. Assume every client is hacked and will do anything and everything it can to cheat.
So given that the clients can and will be hacked, I have no opinion on the client software. Choose whatever you want. Maybe use an obfuscator to slow them down-- but this can make it a pain when debugging client issues.
I do have an opinion about installation. It's much, much easier if there is nothing to install, i.e. the game runs entirely on a web site.
The short answer and this is my opinion, is that there is no technology out there that exists to do what you want. Now there are technologies which increase the difficulty of understanding the client side application. For example Java and .Net are very easy to look at. ByteCode and IL are not secure in any way shape or form. You can add obfuscation to them to raise the bar so to say....but that is still not secure. You could even go to a full blown compiled application but that is still crackable. So long as the computer is able to understand the application then there will be a human somewhere who could break the program apart.
Your approach here is wrong. You should build all logic, all functionality in the server where no one has access, then you use the client applications to simply handle the UX portion. The only safe way to protect your code is not let them have it. And design API's which can't be abused (Don't let the client roll the dice for example)
Related
Is there any way to prevent or detect a man-in-the-middle attack over plain HTTP?
I want to run a javascript applet on a client machine with confidence that the code wasn't modified. Are there any clever tricks to sign the code or deliver it safely without going the usual route of HTTPS and a certificate?
No, not really. By the time you make it secure, you'll have had to reinvent at least 90% of HTTPS (or something very similar, anyway) -- but probably have done an inferior job of it. No insult intended, but very few people are capable of designing something like this adequately. The usual is for a specialist (or a few of them) to design it as well as they can, and still plan on having to fix at least a few problems over the next few years as more cryptanalysts look at it. Chances of a non-specialist getting it right the first time are right up there with those of winning a major lottery and being hit by lightning at exactly the same moment.
In one form or another, public key cryptography would be involved, I believe. You could probably implement it yourself, but it would probably be insecure and difficult. Why do you want to not use HTTPS? It exists for this purpose.
If it's javascript, then you can't even confirm that the person on the client machine hasn't modified your applet whether you use SSL or not.
If they can modify the javascript, then they can remove any checksumming or similar that you put in. Your best bet is to use a javascript obfuscator / minimizer, as that will just make it hard as all hell to change and still run. Yahoo has a good one I believe, as does Google.
This isn't fool-proof but it's probably going to weed out almost everybody considering tampering with your applet. Head over to maps.google.com and have a look at their javascript. Think about sneakily modifying something about it. Probably not gonna happen.
EDIT: this might not be so good after all, see links below
I will soon be developing an application to log and priorities worker shifts. It only needs to be small, and simple, but I am wondering what framework to use. All that needs to happen is boxes with names are in 3 lists, and the user can switch these around at will. It must log the times, which I will need access to in real time.
Im new to application development of this sort, and would like any suggestions. I have time to learn new technologies / languages.
Portability / device independence would also be useful. Should I consider a Web Application in Javascript? or something more like Python.
Thanks.
Even if your application is going to be simple that does not mean that whole system will be simple too. I can imagine that your app will serve only as a front end to something much bigger. If that is a case and you really have freedom to choose what language you will develop your app with consider choosing something that you will feel comfortable to work with. But before you will make your decision I would go to whoever gave you that task and try to get as much information about it as you can because expected features can help in choosing technology.
First of all, it seems that it is up to you to decide if it should be web or desktop app. In my opinion it is completely wrong situation. You should get clear requirements on what kind of application customer expects and in what environment it should work. And I would not move a finger towards a code before somebody gave me that information. You write that portability and device independence would be useful but is it actual requirement or you just think it would be nice feature to deliver?
EDITED (to answer a question in comment)
Probably there is as much possible solutions as people that would answer you so in the end you will have to make your own choices.
One way of doing it (considering that you want to learn something new and have a challenge :) would be implement WCF service that would act as a data provider from your database (so every GetUsers(), GetVacationDays() methods would be in it) and it would take care of some business logic (for example CalculateMaxValidWorkingTime() or whatever). That service would be a real power horse of your system. Since you don't have clear requirement whether it should be desktop or web app you could satisfy both possibilities by creating thin clients that would communicate with your service and they would be just a pretty front ends. And if you keep in mind that you can consume webservices practically with everything from C++ to .NET (C#/VB) to Javascript to Python to PHP after you done with service you would not be constrained with one particular technology/language.
Regarding databases I won't advice because personally I hate dealing with them and it always was somebody else's task to provide me with pretty API :)
My logic of APT (Anti-Paching Technology) is as follows...
1) Store on the MSSQL server the md5 hash of the executable for protection.
2) Perform an md5 comparison (within my application startup) the hash found on the server, with the executable itself.
3) If comparison fails exit application silently.
And all these above before it is finally pached!
I mean what is your best way to protected a file from being patched?
Without using ready tools (.net reactor, virtualizer etc)
Edit: Something else just came into my mind.
Is there any way of checking the application integrity on server side?
I mean my app works only online. Could i execute something on the server (my domain) that could check the application integrity?
The thing is a cracker would patch the application precisely on step 2, removing the hash check code.
So I wouldn't call that very effective against serious crackers.
EDIT: I guess your best bet is defense in depth, given that your app has to be online I'd:
Require authentication: Authenticate users, hopefully via a cryptographic key, and require a key check to receive/send data.
Obfuscation: It makes things harder for crackers.
Continued checks: Besides checking who is sending data, validate the application each time a request is sent.
These all can still be circumvented, but they make things a lot harder and might disuade some if your app is not worth that much to them.
A patched application means the 'cracker' has complete control over the machine the code is running on (at least enough control to patch the executable). So patch prevention however smart it might be is working against the flow of control.
Complicating your binary file might be enough to discourage patching so obfuscators are propably your best bet.
you can't. once someone else has your file they can do what they like with it - first thing would be to patch out your anti-patching code.
If the application is running on someone else's machine, you cannot prevent them from patching it. You can make it harder, but it's a shell game: you cannot win. Regardless of how complicated you make it, some guy somewhere will see it as an interesting challenge to break your protection, and he will succeed. Then, everyone else just has to download his version. The most extreme form of patch-protection today is Skype (that I know of). It's insanely complicated, and yet it has been broken.
Since your application apparently runs online, you can ask yourself why you want to prevent patches in the first place (maybe it's to prevent the user from entering some bad values? Or to prevent them from seeing some information that's present in the program?), and then architect your program so that whatever you want to keep hidden or checked happens on the server.
For example if it's a game and you want to prevent players from hacking the game to know where the other players are: change the server so it only sends coordinate information for the players that you can already see.
Another example: if it's an online store and you want to make sure users don't submit purchase orders with incorrect prices, check the prices at the server.
The only exception there is if you control the hardware that the program's running on. But even there, it's very hard to do it right (see: XBox, PS3, and the many other consoles that tried to do that and failed). It's probably still better to leverage the client/server architecture rather than betting on "trusted computing".
Crackers nowadays don't bother patching your executable file; they simply change your program's variables in-memory to make its behaviour more amenable to their requirements. Defending against this is very difficult and reasonably pointless; most games' crack-protection works only by searching for signatures of known crack programs (like an AV engine does).
Everyone nailed it, you can't stop someone but you can make it harder for them, you could even go off the deep end and make some in-memory validation stuff like World Of Warcrafts Warden system.
If you tell us what language you are writing in we might be able to suggest some simple obfuscation methods.
we know that each executable file can be reverse engineered (disassembled, decompiled). No mater how strong security you will implement, anyway if crackers want to, they do crack!!! Just that is a question of time.
What about websites? May we say that website can be completely safe from attacks of hackers (we assume that hosting is not vulnerable)? If no, than what is the reason?
Yes it is always possible to do. There is always a way in.
It's like my grandfather always said:
Locks are meant to keep the honest
people out
May we say that website can be completely safe from attacks of hackers?
No. Even the most secure technology in the world is vulnerable to social engineering attacks, for one thing.
You can easily write a webapp that is mathematically proven to be secure... But that proof will only hold as long as the underlying operating system, interpreter|compiler, and hardware are secure, which is never the case.
The key thing to remember is that websites are usually part of a huge and complex system and it doesn't really matter if the hacker enters the system through the web application itself or some other part of the entire infrastructure. If someone can get access to your servers, routers, DNS or whatever, they can bring down even the best web application. In my experience a lot of systems are vulnerable in some way or another. So "completely secure" means either "we're trying really hard to secure the platform" or "we have no clue whatsoever, but we hope everything is okay". I have seen both.
To sum up and add to the posts that precede:
Web as a shared resource - websites are useful so long as they are accessible. Render the web site unaccessible, and you've broken it. Denial of service attacks add up to flooding the server so that it can no longer respond to legitimate requests will always be a factor. It's a game of keep away - big server sites find ways to distribute, hackers find ways to deluge.
Dynamic data = dynamic risk - if the user can input data, there's a chance for a hacker to be a menance. Today the big concepts are cross-site scripting and SQL injection, but once one avenue for cracking is figured out, chances are high that another mechanism will rise. You could, conceivably, argue that a totally static site can be secure from this, but then how many useful sites fit that bill?
Complexity = the more complex, the harder to secure - given the rapid change of technology, I doubt that any web developer could say with 100% confidence that a modern website was secure - there's too much unknown code. Taking the host aside (the server, network protocols, OS, and maybe database), there's still all the great new libraries in Java EE and .Net. And even a less enterprise-y architecture will have some serious complexity that makes knowing all potential inputs and outputs of the code prohibitively difficult.
The authentication problem = by definition, the web site lets a remote user do something useful on a server that is far away. Knowing and trusting the other end of the communication is an old challenge. These days server side authenitication is relatively well implemented an understood and (so far as I know!) no one's managed to hack PKI. But getting user authentication ironed out is still quite tricky. It's doable, but it's a tradeoff between difficulty for the user and for configuration, and a system with a higher risk of vulnerability. And even a strong system can be broken when users don't follow the rules or when accidents happen. All this doesn't apply if you want to make a public site for all users, but that severely limits the features you'll be able to implement.
I'd say that web sites simply change the nature of the security challenge from the challenges of client side code. The developer does not need to be as worried about code replication, but the developer does need to be aware of the risks that come from centralizing data and access to a server (or collection of servers). It's just a different sort of problem.
Websites suffer greatly from injection and cross site scripting attacks
Cross-site scripting carried out on
websites were roughly 80% of all
documented security vulnerabilities as
of 2007
Also part of a website (in some web sites a great deal) is sent to the client in the form of CSS, HTML and javascript, which is the open for inspection by anyone.
Not to nitpick, but your definition of "good hosting" does not assume the HTTP service running on the host is completely free from exploits.
Popular web servers such as IIS and Apache are often patched in order to protect against such exploits, which are often discovered the same way exploits in local executables are discovered.
For example, a malformed HTTP request could cause a buffer overrun on the server, leading to part of its data being executed.
It's not possible to make anything 100% secure.
All that can be done is to make something hard enough to break into, that the time and effort spent doing so makes it not worth doing.
Can I crack your site? Sure, I'll just hire a few suicide bombers to blow up your servers. Or... I'll blow up those power plants that power up your site, or I do some sort of social engineering, and DDOS attacks would quite likely be effective in a large scale not to mention atom bombs...
Short answer: yes.
This might be the wrong website to discuss that. However, it is widely known that security and usability are inversely related. See this post by Bruce Schneier for example (which refers to another website, but on Schneier's blog there's a lot of interesting readings on the issue).
Assuming the server itself isn't comprimised, and has no other clients sharing it, static code should be fine. Things usually only start to get funky when there's some sort of scripting language involved. After all, I've never seen a comprimised "It Works!" page
Saying 'completely secure' is a bad thing as it will state two things:
there has not been a proper threat analysis, because secure enough would be the 'correct' term
since security is always a tradeoff it means that the a system that is completely secure will have abysmal usability and the site will be a huge resource hog as security has been taken to insane levels.
So instead of trying to achieve "complete security" you should;
Do a proper threat analysis
Test your application (or have someone professional test it) against common attacks
Apply best practices, not extreme measures
The short of it is that you have to strike a balance between ease of use and security, much of the time, and decide what provides the optimal level of both for your purposes.
An excellent case in point is passwords. The easy way to go about it is to just have one, use it everywhere, and make it something easy to remember. The secure way to go about it is to have a randomly generated variable-length sequence of characters across the encoding spectrum that only the user himself knows.
Naturally, if you go too far on the easy side, the user's data is easy to pick off. If you go too far on the side of security, however, practical application could end up leading to situations that compromise the added value of the security measures (e.g. people can't remember their whole keychain of passwords and corresponding user names, and therefore write them all down somewhere. If the list is compromised, the security measures that had been put into place are for naught. Hence, most of the time a balance gets struck and places ask that you put a number in your password and tell you not to do anything stupid like tell it to other people.
Even if you remove the possibility of a malicious person with the keys to everything leaking data from the equation, human stupidity is infinite. There is no such thing as 100% security.
May we say that website can be completely safe from attacks of hackers (we assume that hosting is not vulnerable)?
Well if we're going to start putting constraints on the attacker, then of course we can design a completely secure system: we just have to bar all of the attacker's attacks from the scenario.
If we assume the attacker actually wants to get in (and isn't bound by the rules of your engagement), then the answer is simply no, you can't be completely safe from attacks.
Yes, it's possible for a website to be completely secure, for a reasonable definition of 'complete' that includes your original premise that the hosting is not vulnerable. The problem is the same as with any software that contains defects; people create software of a complexity that is slightly beyond their capability to manage and thus flaws remain undetected until it's too late.
You could start smaller and prove all your work correct and safe as you construct it, remaking any off-the-shelf components that haven't been designed to that stringent degree of quality, but unfortunately that leaves you at a massive commercial disadvantage compared to the people who can write 99% safe software in 1% of the time. Therefore there's rarely a good business reason for going down this path.
The answer to this question lies close to the ideas about computational theory that arise from considering the halting problem. http://en.wikipedia.org/wiki/Halting_problem To wit, if you could with clarity say you'd devised a way to programmatically determine if any particular program was secure, you might be close to disproving the undecidability of the halting problem on the class of machines you were working with. Since the undecidability of the halting problem has been proven, we can know that over turing machines you would be unable to prove securability since the problem of security reduces to the halting problem. Even for finite machines you might be able to decide all of the states of the program, but Minsk would tell us that the time required for a complete state tree for even simplistic modern day machines and web servers would be huge. You probably know a lot about a specific piece of code, but as soon as you changed the code, or updated it, a complete retest would be required. Fundamentally this is interesting because it all boils back to the concept of information and meaning. Read about Automated theory proving to understand more about the limits of computational systems. http://en.wikipedia.org/wiki/Automated_theorem_proving
The fact is hackers are always one step ahead of developers, you can never ever consider a site to be bullet proof and 100% safe. You just avoid malicious stuff as much as you can !!
In fact, you should follow whitelist approach rather than blacklist approach when it comes to security.
I have a Linux web server and I'd like to make some database tables (currently in Access) available on the web for CRUD. There needs to role-based security. What's the quickest path to develop this?
Also, which database would be best? I already have mySQL running on that box if it makes any difference.
I agree with Chuck, the question shouldn't really be about the language, but about the framework you choose.
I did something similar to you a while back, and ended up using Ruby on Rails, and the activescaffold plugin (http://www.activescaffold.com/) to provide a pretty front end. The actual code I ended up writing was extremely minimal. There are other plugins for Rails which provide role based security too (which I didn't bother with, I just had "you're either logged in and have write access, or you're not logged in and you don't") and which also mean you don't have to write much stuff yourself.
So put me in the camp for Rails come the religious war ;)
Edit: MySQL is a perfect database to use, so you don't have to worry there.
This will turn into a religious war between the Ruby on Rails camp and the Python camp, with a good smattering of the PHP and Perl. You should evaluate the langauges yourself and decide what is best for you. There are, of course, other choices, however listing those would just elicit mroe religious battles. Although, I would say all of those I listed would be reasonable choices. You can usually create a good design in spite of any shortcommings your chosen language may have.
I don't think language is the question you should be asking. There's no language particularly well-suited to CRUD Web apps. There are many frameworks designed for that sort of thing, though, in many different languages, and those are probably what you'll want to look at.
I think Rails is the best in general, and that's what I use for most projects. It's very well-suited to CRUD apps (to the point where it allows you to create a simple one without writing any code at all). But if there really were an undisputed "best" choice, you'd probably already know about it. Instead, some apps are made with Rails, some with Django, some with Cake, and so on and so forth.
If you want a solid, clean, stable CRUD web app that can be maintained and expanded for years to come, stick with the standards: PHP, Perl, JavaScript, CSS, and HTML. Learn those roots languages well. Take the time to do it right and focus on good coding habits like clarity, consistency, and organization. Practice good reuse of code, good naming, good commenting, and good database design. Test, document, and refactor. Take pride in the craftsmanship of your CRUD app. Learn it inside and out. Set the stage so you can later maintain and expand it. Your goal is to build something that will work well, last a long time, and make a great return on the business investment. Someone once said that it takes 10 years to become a good coder.
As for frameworks, plugins, and external libraries, that's wonderful icing to put on your cake. But never confuse the icing with the cake. If you want to learn to code, take the time to learn it right. If you're not comfortable coding a simple CRUD app, you'll be even less comfortable trying to navigate the framework-generated code. Coding is a wonderful gig. But never mistake the sizzle for the steak.