Reputation: 13871
There are tons of good papers about designing and developing for security (and even a bunch of posts on SO), but all of them seem to concentrate on what you should do.
What I'm after, however, is a think-like-a-hacker checklist. A list of simple actions you should to go through once you're done with development, to make sure the solution is secure.
(UPDATE: I'm mostly interested in a blackbox checklist - "go to a page, try this and that" kind of things, but a whitebox checklist might be of interest as well.)
Here's something I've come up with so far:
HtmlEncode
and UrlEncode
http://www.example.com/foo?bar=HugeAmountOfData
to make sure you constrain inputs and do boundary checks.Web tier.
[ValidateAntiForgeryToken]
attribute to prevent Cross-Site Request Forgery attacks. Response.Write
(either directly or indirectly) is never used to display user input.Service tier.
Database tier.
SELECT *
but always specify the list of columns explicitly.@@TRANCOUNT
, etc) and explicitly commit/rollback it.Comments? Corrections? Missing steps?
Making it a community wiki, feel free to edit as much as you like.
Upvotes: 20
Views: 3385
Reputation: 1
To add to the list:
Black: DoS attacks - employ tinyget or similar to simulate DoS attacks, see what your app does.
Black: Canonicalization attacks. Mentioned a bit, may be special focus can be on a directory traversal attack in case of downloads.
White: Usage of cookies for the sensitive info? See cookies are not used for sensitive data and are not persisted locally over the intented interval. Black: Sniff in the temp IE/XYZ folder for cookies.
Black: Again, use scripted tinyget or try manually to see if brute force password guess would work or if you app has smart delays/denials for a password guess attacks.
Black: Do any of the attacks and see if admin is notified automatically of the attack or it is only the attacker who knows about it.
"Make sure your security decisions do not rely on HTTP headers info" - http headers are used for ntml/kerberos authentication? May be just don't use them stupidly, don't invent or rely on referer, etc?
General: Employ a commercial black/white-box security scanner, can be expensive but can be hard to do security regression tests otherwise.
Upvotes: 4
Reputation: 13536
Make sure you don't blindly bind form data to your model by always using TryUpdateModel<T>
over TryUpdateModel
.
Upvotes: 1
Reputation: 126547
Sticking mostly to MVC-specific stuff:
<%:
and MvcHtmlString
.JsonRequestBehavior.AllowGet
to ensure it cannot return an array.robots.txt
Upvotes: 4
Reputation:
User credentials are validated on each request, either GET or POST or other, to confirm the user authentication
Check user authorization (after checking authentication) for each sensitive operation
Watch out output caching, especially if you implement your own membership system
Upvotes: 1