Web applications on uncompromised computers are vulnerable to XSS,CRSF,sql injection attacks and cookie stealing in unsecure wifi environments.
To prevent those security issues there are the folowing remedies
sql injection: a good datamapper(like linq-to-sql) does not have the risk of sql injection (am i naïeve to believe this?)
CSRF: Every form-post is verified with the <%:Html.AntiForgeryToken() %> (this is a token in a asp.net mvc environment that is stored in a cookie and verified on the server)
XSS: every form that is allowed to post html is converted, only bb code is allowed, the rest is encoded . All possible save actions are done with a post event so rogue img tags should have no effect
cookie stealing: https
Am i now invulnerable to web-based hacking attempts(when implemented correctly)? Or am i missing some other security issues in web-development?(except for possible holes in the OS platform or other software)
The easy answer is "No you're not invulnerable - nobody is!"
This is a good start, but there are a few other things you could do. The main one you haven't mentioned is validation of untrusted data against a white-list and this is important as it spans multiple exploits such as both SQLi and XSS. Take a look at OWASP Top 10 for .NET developers part 1: Injection and in particular, the section about "All input must be validated against a whitelist of acceptable value ranges".
Next up, you should apply the principle of least privilege to the accounts connecting to your SQL Server. See the heading under this name in the previous link.
Given you're working with ASP.NET, make sure Request Validation remains on and if you absolutely, positively need to disable it, just do it at a page level. More on this in Request Validation, DotNetNuke and design utopia.
For your output encoding, the main thing is to ensure that you're encoding for the right context. HTML encoding != JavaScript encoding != CSS encoding. More on this in OWASP Top 10 for .NET developers part 2: Cross-Site Scripting (XSS).
For the cookies, make them HTTP only and if possible, only allow them to be served securely (if you're happy to only run over HTTPS). Try putting your web.config through the web.config security analyser which will help point you in the right direction.
Another CSRF defense - albeit one with a usability impact - is CAPTCHA. Obviously you want to use this sparingly but if you've got any really critical functions you want to protect, this puts a pretty swift stop to it. More in OWASP Top 10 for .NET developers part 5: Cross-Site Request Forgery (CSRF).
Other than that, it sounds like you're aware of many of the important principles. It won't make you invulnerable, but it's a good start.
Am I now invulnerable to web-based hacking attempts?
Because, no matter how good you are, everyone makes mistakes, the answer is no. You almost certainly forgot to sanitize some input, or use some anti-forgery token. If you haven't now, you or another developer will as your application grows larger.
This is one of the reason we use frameworks - MVC, for example, will automatically generate anti-CSRF tokens, while LINQ-to-SQL (as you mentioned) will sanitize input for the database. So, if you are not already using a framework which makes anti-XSS and anti-CSRF measures the default, you should begin now.
Of course, these will protect you against these specific threats, but it's never possible to be secure against all threats. For instance, if you have an insecure SQL-connection password, it's possible that someone will brute-force your DB password and gain access. If you don't keep your versions of .Net/SQL-Server/everything up to date, you could be the victim of online worm (and even if you do, it's still possible to be zero-dayed).
There are even problems you can't solve in software: A script kiddie could DDOS your site. Your server-company could go bankrupt. A shady competitor could simply take a hedge-clippers to your internet line. Your warehouse could burn down. A developer could sell the source-code to a company in Russia.
The point is, again, you can't ever be secure against everything - you can only be secure against specific threats.
This is the definitive guide to web attacks. Also, I would recommend you use Metasploit against your web app.
It definitely is not enough! There are several other security issues you have to keep in mind when developing a web-app.
To get an overview you can use the OWASP Top-Ten
I think this is an very interesting post to read when thinking about web-security: What should a developer know before building a public web site?
There is a section about security that contains good links for most of the threats you are facing when developing web-apps.
The most important thing to keep in mind when thinking about security is:
Never trust user input!
[I am answering to this "old" question because I think it is always an actual topic.]
About what you didn't mention:
You missed a dangerous attack in MVC frameworks: Over Posting Attack
You also missed the most annoying threats: Denial of Service
You also should pay enough attention to file uploads (if any...) and many more...
About what you mentioned:
XSS is really really really waster and more annoying to mitigate. There are several types of encoding including Html Encoding, Javascript Encoding, CSS Encoding, Html Attribute Encoding, Url Encoding, ...
Each of them should be performed to the proper content, in the proper place - i.e. Just doing Html Encoding the content is not enough in all situations.
And the most annoying about XSS, is that there are some situations that you should perform Combinational Encoding(i.e. first JavascriptEncode and then HtmlEncode...!!!)
Take a look at the following link to become more familiar with a nightmare called XSS...!!!
XSS Filter Evasion Cheat Sheet - OWASP
Related
I am currently working on security for a website (JSP) that contains 2 pages: a login and a data page. Once a user logs in, he is able to SELECT data from a specific table with read only access.
After browsing security risks online, I have wrote down a general list of what I might have to defend against
Injections
XSS
Auth / Session hijacking
CSRF
Direct Object Ref
Currently, I am reading about how to defend these attacks and what I should include in my code. However, I won't really know if my code actually works unless I test these attacks out for myself (and even then, there still might be other attacks that work). Right now, I just want some security, and thus I need to know how to produce these attacks so I can try them on my site.
Injections were simple as all I had to do what type '1'='1 in my code to reveal that it was flawed. Then I used prepared statements and SQL injections didn't work anymore.
How can I produce the rest of these attacks to see if my security atleast works against basic attacks?
(Also, is there perhaps some safe site or tool I can use to test out my vulnerabilities?)
I assume from your list that you're looking at the Open Web Application Security Project Top Ten. Good!
Really, the best advice I can give is to read through the OWASP site. A good first step would be to go through the individual links on that page (e.g. Broken Authentication and Session Management) and check the "Am I vulnerable?" section. Here are some further hints:
XSS
The XSS Cheat Sheet can be pretty helpful here. More examples than you can shake a stick at, ready to paste into your site.
CSRF
OWASP's wiki has a CSRF Testing Guide full of great links and suggestions.
Auth/Session hijacking
Well, are you using HTTPS? See this answer for more.
More resources
If you want to Go Deeper and do some real testing, here are some things you can do:
Read the Web Application Hacker's Handbook.
Try out some of the examples on http://hackthissite.org and the Google Gruyere project and see if you can break into them.
Download Kali Linux and learn to use some of the tools that come with it.
Go to a security conference or minicon near you and connect with other infosec people. Maybe I'll see you there :)
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.
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. :)
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".
For the sake of simplicity I want to use admin links like this for a site:
http://sitename.com/somegibberish.php?othergibberish=...
So the actual URL and the parameter would be some completely random string which only I would know.
I know security through obscurity is generally a bad idea, but is it a realistic threat someone can find out the URL? Don't take the employees of the hosting company and eavesdroppers on the line into account, because it is a toy site, not something important and the hosting company doesn't give me secure FTP anyway, so I'm only concerned about normal visitors.
Is there a way of someone finding this URL? It wouldn't be anywhere on the web, so Google won't now it about either. I hope, at least. :)
Any other hole in my scheme which I don't see?
Well, if you could guarantee only you would ever know it, it would work. Unfortunately, even ignoring malicious men in the middle, there are many ways it can leak out...
It will appear in the access logs of your provider, which might end up on Google (and are certainly read by the hosting admins)
It's in your browsing history. Plugins, extensions etc have access to this, and often use upload it elsewhere (i.e. StumbleUpon).
Any proxy servers along the line see it clearly
It could turn up as a Referer to another site
some completely random string
which only I would know.
Sounds like a password to me. :-)
If you're going to have to remember a secret string I would suggest doing usernames and passwords "properly" as HTTP servers will have been written to not leak password information; the same is not true of URLs.
This may only be a toy site but why not practice setting up security properly as it won't matter if you get it wrong. So hopefully, if you do have a site which you need to secure in future you'll have already made all your mistakes.
I know security through obscurity is
generally a very bad idea,
Fixed it for you.
The danger here is that you might get in the habit of "oh, it worked for Toy such-and-such site, so I won't bother implementing real security on this other site."
You would do a disservice to yourself (and any clients/users of your system) if you ignore Kerckhoff's Principle.
That being said, rolling your own security system is a bad idea. Smarter people have already created security libraries in the other major languages, and even smarter people have reviewed and tweaked those libraries. Use them.
It could appear on the web via a "Referer leak". Say your page links to my page at http://entrian.com/, and I publish my web server referer logs on the web. There'll be an entry saying that http://entrian.com/ was accessed from http://sitename.com/somegibberish.php?othergibberish=...
As long as the "login-URL" never posted anywhere, there shouldn't be any way for search engines to find it. And if it's just a small, personal toy-site with no personal or really important content, I see this as a fast and decent-working solution regarding security compared to implementing some form of proper login/authorization system.
If the site is getting a big number of users and lots of content, or simply becomes more than a "toy site", I'd advice you to do it the proper way
I don't know what your toy admin page would display, but keep in mind that when loading external images or linking to somewhere else, your referrer is going to publicize your URL.
If you change http into https, then at least the url will not be visible to anyone sniffing on the network.
(the caveat here is that you also need to consider that very obscure login system can leave interesting traces to be found in the network traces (MITM), somewhere on the site/target for enabling priv.elevation, or on the system you use to log in if that one is no longer secure and some prefer admin login looking no different from a standard user login to avoid that)
You could require that some action be taken # of times and with some number of seconds of delays between the times. After this action,delay,action,delay,action pattern was noticed, the admin interface would become available for login. And the urls used in the interface could be randomized each time with a single use url generated after that pattern. Further, you could only expose this interface through some tunnel and only for a minute on a port encoded by the delays.
If you could do all that in a manner that didn't stand out in the logs, that'd be "clever" but you could also open up new holes by writing all that code and it goes against "keep it simple stupid".