Paranoid attitude: What's your degree about web security concerns? - security

this question can be associated to a subjective question, but this is not a really one.
When you develop a website, there is several points you must know: XSS attacks, SQL injection, etc.
It can be very very difficult (and take a long time to code) to secure all potential attacks.
I always try to secure my application but I don't know when to stop.
Let's take the same example: a social networking like Facebook. (Because a bank website must secure all its datas.)
I see some approaches:
Do not secure XSS, SQL injection... This can be really done when you trust your user: back end for a private enterprise. But do you secure this type of application?
Secure attacks only when user try to access non owned datas: This is for me the best approach.
Secure all, all, all: You secure all datas (owner or not): the user can't break its own datas and other user datas: this is very long to do and is it very useful?
Secure common attacks but don't secure very hard attacks (because it's too long to code comparing to the chance of being hacked).
Well, I don't know really what to do... For me, I try to do 1, 2, 4 but I don't know if it's the great choice.
Is there an acceptable risk to not secure all your datas? May I secure all datas but it takes me double time to code a thing? What's the enterprise approach between risk and "time is money"?
Thank you to share this because I think a lot of developers don't know what is the good limit.
EDIT: I see a lot of replies talking about XSS and SQL injection, but this is not the only things to take care about.
Let's take a forum. A thread can be write in a forum where we are moderator. So when you send data to client view, you add or remove the "add" button for this forum. But when a user tries to save a thread in server side, you must check that user has the right to dot it (you can't trust on client view security).
This is a very simple example, but in some of my apps, I've got a hierarchy of rights which can be very very difficult to check (need a lot of SQL queries...) but in other hand, it's really hard to find the hack (datas are pseudo encrypted in client view, there is a lot of datas to modify to make the hack runs, and the hacker needs a good understanding of my app rules to do a hack): in this case, may I check only surface security holes (really easy hack) or may I check very hard security holes (but it will decrease my performances for all users, and takes me a long time to develop).
The second question is: Can we "trust" (to not develop a hard and long code which decreases performance) on client view for very hard hack?
Here is another post talking of this sort of hack: (hibernate and collection checking) Security question: how to secure Hibernate collections coming back from client to server?

I think you should try and secure everything you can, the time spent doing this is nothing compared to the time needed to fix the mess done by someone exploiting a vulnerability you left somewhere.
Most things anyway are quite easy to fix:
sql injections have really nothing to do with sql, it's just string manipulation, so if you don't feel comfortable with that, just use prepared statements with bound parameters and forget about the problem
cross site exploit are easily negated by escaping (with htmlentities or so) every untrusted data before sending it out as output -- of course this should be coupled with extensive data filtering, but it's a good start
credentials theft: never store data which could provide a permanent access to protected areas -- instead save a hashed version of the username in the cookies and set a time limit to the sessions: this way an attacker who might happen to steal this data will have a limited access instead of permanent
never suppose that just because a user is logged in then he can be trusted -- apply security rules to everybody
treat everything you get from outside as potentially dangerous: even a trusted site you get data from might be compromised, and you don't want to fall down too -- even your own database could be compromised (especially if you're on a shared environment) so don't trust its data either
Of course there is more, like session hijacking attacks, but those are the first things you should look at.
EDIT regarding your edit:
I'm not sure I fully understand your examples, especially what you mean by "trust on client security". Of course all pages with restricted access must start with a check to see if the user has rights to see the content and optionally if he (or she) has the correct level of privilege: there can be some actions available to all users, and some others only available to a more restricted group (like moderators in a forum). All this controls have to be done on the server side, because you can never trust what the client sends you, being it data through GET, POST and even COOKIES. None of these are optional.

"Breaking data" is not something that should ever be possible, by the authorized user or anybody else. I'd file this under "validation and sanitation of user input", and it's something you must always do. If there's just the possibility of a user "breaking your data", it'll happen sooner or later, so you need to validate any and all input into your app. Escaping SQL queries goes into this category as well, which is both a security and data sanitation concern.
The general security in your app should be sound regardless. If you have a user management system, it should do its job properly. I.e. users that aren't supposed to access something should not be able to access it.
The other problem, straight up XSS attacks, has not much to do with "breaking data" but with unauthorized access to data. This is something that depends on the application, but if you're aware of how XSS attacks work and how you can avoid them, is there any reason not to?
In summary:
SQL injection, input validation and sanitation go hand in hand and are a must anyway
XSS attacks can be avoided by best-practices and a bit of consciousness, you shouldn't need to do much extra work for it
anything beyond that, like "pro-active" brute force attack filters or such things, that do cause additional work, depend on the application
Simply making it a habit to stick to best practices goes a long way in making a secure app, and why wouldn't you? :)
You need to see web apps as the server-client architecture they are. The client can ask a question, the server gives answers. The question is just a URL, sometimes with a bit of attached POST data.
Can I have /forum/view_thread/12345/ please?
Can I POST this $data to /forum/new_thread/ please?
Can I have /forum/admin/delete_all_users/ please?
Your security can't rely only on the client not asking the right question. Never.
The server always needs to evaluate the question and answer No when necessary.

All applications should have some degree of security. You generally don't ask for SSL on intranet websites, but you need to take care of SQL/XSS attacks.
All data your user enters into your application should be under your responsibility. You must make sure nobody unauthorized get access to it. Sometimes, a "not critical" information can pose a very security problem, because we're all lazy people.
Some time ago, a friend used to run a games website. Users create their profiles, forum , all that stuff. Then, some day, someone found a SQL injection open door somewhere. That attacker get all user and password information.
Not a big deal, huh? I mean, who cares about a player account into a website? But most users used same user/password to MSN, Counter Strike, etc. So become a big problem very fast.
Bottom line is: all applications should have some security concern. You should take a look into STRIDE to understand your attack vectors and take best action.

I personally prefer to secure everything at all times. It might be a paranoid approach, but when I see tons of websites throughout internet, that are vulnerable to SQL injection or even much simpler attacks, and they are not bothered to fix it until someone "hacks" them and steal their precious data, it makes me pretty much afraid. I don't really want to be the one responsible for leaked passwords or other user info.
Just ask someone with hacking experiences to check your application / website. It should give you a fair idea what's wrong and what should be updated.
You want to have strong API side ACL. Some days ago I saw a problem where a guy had secured every single UI, but the website was vulnerable through AJAX, just because his API (where he was sending requests) just trusted every single request to be checked. I could basically pull whole database through this bug.

I think it's helpful to distinguish between preventing code injection and plain data authorization.
In my opinion, all it takes is a few good coding habits to completely eliminate SQL injection. There is simply no excuse for it.
XSS injection is a little bit different - i think it can always be prevented, but it may not be trivial if your application features user generated content. By that I simply mean that it may not be as trivial to secure your app against XSS as it is compared to SQL injection. So I do not mean that it is ok to allow XSS - I still think there is no excuse for allowing it, it's just harder to prevent than SQL injection if your app revolves around user generated content.
So SQL injection and XSS are purely technical matters - the next level is authorization: how thoroughly should one shield of access to data that is no business of the current user. Here I think it really does depend on the application, and I can imagine that it makes sense to distinguish between: "user X may not see anything of user Y" vs "Not bothering user X with data of user Y would improve usability and make the application more convenient to use".

Related

What is the security standard for a small business?

This maybe a very newbie question, but exactly what do I need so that I can say my network is considered "secure"?
To be more specific, if I have a website that deals with login/signup and lots of money transactions, what do I need to protect it?
So far I know I need EV SSL certificate, login system protections like brute force login protection, hashing the password, key stretching. Is there anything I missed?
Besides, is firewall really necessary in my case? I just feel like everything I want to do can be accomplished by the server itself, so is there really a need to get a software/hardware firewall?
To be completely blunt, you should probably hire a security professional to assess and make recommendations about your site. Alternatively, a part or full-time network administrator with security experience/certifications might be a good hire.
I recommend the "don't do-it-yourself" approach not because I want to increase work for my peers, or that I don't believe you are a fully competent individual. Rather, I recommend it because security is really, really hard to get right, and any site that handles money is an ideal target for any attacker out there. From a professional perspective, you would be best served by getting an expert to secure your network, perhaps on an ongoing basis; this is a situation that security professionals are very used to, and very well equipped to handle. From a legal perspective, getting an expert opinion on such a sensitive matter is essential due diligence, and trying to do it entirely on your own opens you to significant liability if your system gets breached and attackers are able to carry off your customer's data. Which, as your business grows and you gain more visibility online, only more and more likely to happen without ongoing, professional help.

Mitigating botnet brute force attack with Javascript Detection?

Hi this is my first post here. I am developing a website project with public user registration and log in functions. Right now, I am conceptualizing the logic flow of the whole project and currently stuck at the authentication and security part.
I have googled and unable to find an answer. I also searched sof but effort is futile as well. What I want to ask is quite specific.
From what I read at other sof posts, it seems that to mitigate a brute-force attack, ip banning or time delay after n number of attempted log ins is one of the best solutions. Of course not forgetting whitelisting and blacklisting and Captcha. Of course I already plan to implement the above-mentioned techniques.(maybe not captcha)
My question is, is it possible to detect javascript enabled or unabled to block illegitimate log-in attempts base on the assumption that bot-net or 'hackers' do not use a javascript enabled browser to do their 'work'?
For example, "if js disabled, stop the 'rendering' of the log-in
form. //brute force attempt detected"
Finally, this assumption is base on the fact that all of my users will have a js enabled browser in order to use my website.
This approach will be run concurrent with other mitigate methods.
Please enlighten.
Thanks!
Not reliably or efficiently. You can't really trust anything that comes from the client side.
Anything you ask the client to do in javascript to prove that javascript is present can be impersonated. Forcing them to impersonate will force them to be more intelligent and expend more resources, which might be a win for you.
While u2702 makes a good point, I think it's good to keep in mind that just because a solution doesn't dissuade all attackers doesn't mean it should be abandoned. In fact, I think this is a quite good method to deter the vast majority of bots.
To answer the question at hand, you could have all prospective users calculate the MD5 of a value you've generated using a cryptographically secure random function. Faking this without javascript would be more-or-less impossible (as far as I can see).
Disclaimer: Implementation of this method will ban Richard Stallman and people who use NoScript from your site.

php user management systems

I'm on my last steps to open my website, but the only thing that drove me crazy is the php user management. I found a lot of resources about building these systems and I believe that I can write them in my own way. The thing is that when it comes to security I get so freaking out what to go with. For example, when it comes to sending sensitive information over SSL, some people suggest to make sure that the info is encrypted in the registration form so that attacker can't hack it. And some other suggest to make sure that the debugging messages don't show when an error happen so that the attacker can't retrace the links .etc.
now as I read from here and there that md5 is not safe anymore so I'm wondering how would hash new user password and etc... I found a link to some programmers who already offer some user management, but not sure if they are good enough since I'm concerned about security as a priority CodeCanyon
so now what are the security measures that I have to be focusing on?
are there any resources related to that?
Thanks,
You don't have to (you shouldn't) choose between the different things people tell you to implement. Good security is always layered, meaning that you implement as many protections as you can. This approach has multiple purposes. Each layer can prevent different attacks. Each layer can prevent attackers with different experience. Each layer can increase the time needed for an attacker.
Here are some tipps useful for authentication systems.
Don't show debugging outputs
Don't use MD5 hashes. SHA2 or even better, bcrypt are much better
Use salts when storing passwords
Use nonces on your forms (one time tokens)
Always require SSL encryption between server and client
When accessing your database on the server, make sure that information leakage or its client-side manipulation not possible (eg.
avoid injection attacks, with database drivers use prepared
statements, etc.)
Make sure all failed logins (no matter what the reason) take the same amount of time to prevent timing attacks
When a logged-in user starts a risky operation (changing pwd, payment etc.), re-authgenticate him
Never store passwords cleartext, not ever, not anywhere
Require a minimum complexity for the password
!!! Secure your php sessions (another large topic, worth its own discussion) -
As you can see, there a lot you can do (and more people will probably tell you even more stuff), what you really should do depends on the risks you are willing to accept. But never rely on a single security measure, always have a layered approach.
Answering your direct question: It has been proven that MD5 does have collisions and there are rainbow tables floating around (see Wikipedia). PHP does have quite some hash functions available all having different advantages and disadvantages. Please also see the comment section on php.net.
Concerning general web application security I'd recommend you take a look at the OWASP project that is about making web applications more secure. A good start would be to take a look at the Top Ten security vunerabilities ("Top Ten" in the blue box).
use sha1 for storing password , prevent sql injection and xss script as input field.
session hijacking , fixation prevention.
At first you should send your data via SSL (TSL) to the server, this will encrypt. Also you should use a CSRF protection for any form you send to the server.
When you have implemented your functions and they work you should try to hack your site by yourself. Try to inject SQL, JS through the forms, try to manipulate the date after the form was send, you can also try to produce erros that will be written to you PHP error log even that could be executed if your server settings are weak. (http://en.wikipedia.org/wiki/Hardening_(computing))
When you store the password in your database use an seeded hash function, if anyone is able to hack your database and get the hashs he will not be able to encrypt them without the seed.
Your will find many information about all the techniques via google.

What is the best login design for web applications?

First, let's define "best" here. The "best" login design/flow/algorithm/technique for the purposes of this question should be:
Simple. I don't think I need to explain why a simple system is better than a complicated one. OAuth 2, for example, is a very complicated system in my view. It defines, if I recall correctly, no less than nine different flows for granting an application access to a person's data. I find this superfluous, but that's not up for debate here.
Language-agnostic. Please do not answer by giving an implementation. I don't want an implementation. I want a design (or several...). You can give examples, but the solution you propose should be easy to code in any (read: most) language without requiring significant workarounds for features that aren't there.
Secure. The design should cover most common security problems on the net. XSS, CSRF, etc etc etc. I think a good set would be obtainable by going to Coding Horror and searching for "security"...
Now for some smaller details:
JavaScript is allowed. If a design can fall back to noscript environments, cool. But it's not a requirement.
Flash, Java applets are not allowed. This goes against the language-agnostic clause above: if your design requires something that is only available through Flash or Java, it's a flaw.
Password storage. There's a whole class of problems related to password storage. I don't want to hear about it.
Password transmission. This is important. Transmitting a password in plain is just plain evil. Over SSL, it might be acceptable, but if you can have a system that is (relatively) secure without relying onto end-to-end encryption, it would be awesome.
Given all this, propose the "best" user/login/logout design/flow/algorithm/technique you think fits the conditions outlined above. Or tell me if you think it's a fool's errand! ;)
I think you have already given some thought to this question. Easiest way to look at the solution is to break it in to different layers.
1) Database
Protected against sql injection. Just use prepared statements. Best and most secure!
Always and I mean always, make sure the db user has only the access privileges it needs.
2) Application
Use HTTPS. Don't even try to use anything else
Don't store user-id in the cookie or anything. Use session's if you must
If you don't have a session, generate a random id use that to look up a user. It's important to not have the cookie id not predictable.
3) HTML/Javascript
Protect against CSRF by doing a token system. This is the only legit way
Escape all you user input and sanitize it before writing to stream. In JSP, for example <c:out/> should be used
Don't do anything secure in javascript. This is an obvious answer but sometimes it good to remind
4) Etc
Keep patches up to date
Don't recreate the wheel. In Rails, there are already some excellent authorization gems. Use them!
I think out all of these, using SSL is the most important. You can create the most complicated system to do a double submit with an awesome encyrption algorithm. But with all of that, at the end, you still won't have a system that is more secure and better tested than SSL.
Interesting question.
I would consider:
When required I think web content should be public. So, as a user, I think it's best to have login only when it is required
SSO We should have mechanism to cross connect web applications more easily. I know that applications do not implement permissions the same way and we can't go wild there. That's where OAuth is filling the gap.
Do not use CAPTCHA (it is considered inaccessible). Unless you use something similar, like these
csrf hidden field to make sure that the form that are submitting is a valid one and not a random post to an endpoint
Always use SSL the big guys is doing it and it's unsafe to let our users send their passwords in clear text. Some proved it.
Always plan for without javascript Just in case, anyway it's not because we can do it that it's good to do.
That's my timeout for tonight. :)

Website hacking - Why it is always possible to do?

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.

Resources