Home/ Questions/Q 586003
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T15:03:43+00:00

There are tons of good papers about designing and developing for security (and even

  • 0

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:

Security Blackbox Checklist

  • Submit incorrect/malicious data (examples here?) to make sure that input is validated for type, length, format and range by javascript.
  • Turn off client-side validation and repeat the step above, to make sure that
    • you don’t only check with javascript but validate on the server side as well
    • input is validated on the server for type, length, format, and range
    • free form input is sanitized
    • output that includes input is encoded with HtmlEncode and UrlEncode
  • Insert extremely large amount of data in the query string as per http://www.example.com/foo?bar=HugeAmountOfData to make sure you constrain inputs and do boundary checks.
  • Visit a POST action via GET, to make sure that “form submit” actions are restricted to be POST-only.
  • If applicable, upload a file of incorrect size/format (huge file, empty file, executable with renamed extension, etc) to make sure uploads are handled gracefully.
  • (how to check from UI?) ensure that absolute URLs are used for navigation.
  • Access the URL as a user without correct permissions, to make sure permissions are explicitly tested via action/controller attributes.
  • Access the URL providing non-existing details (like non-existing product ids, items you don’t have access to, etc) to make sure a correct error (404 or 403 etc) is returned.
  • Access the sensitive page via HTTP, to make sure it’s available via HTTPS only.

Security Whitebox Checklist

Web tier.

  • In debug mode, break the code so that it throws an exception, to make sure it fails securely. Make sure you catch exceptions and log detailed messages but do not leak information to the client.
  • If applicable, make sure MVC actions, are restricted on POST/GET only, particular user role, anything else?.
  • Make sure POST actions are accompanied with [ValidateAntiForgeryToken] attribute to prevent Cross-Site Request Forgery attacks.
  • Make sure Response.Write (either directly or indirectly) is never used to display user input.
  • Make sure sensitive data is not passed in query strings or form fields.
  • Make sure your security decisions do not rely on HTTP headers info.

Service tier.

  • In debug mode, break the code so that it throws an exception, to make sure it fails securely. Make sure you catch exceptions and log detailed messages but do not leak information to the client.
  • Ensure that if updating anything in the database you operate within a transaction.

Database tier.

  • Ensure that retrieval stored procs don’t use SELECT * but always specify the list of columns explicitly.
  • Ensure that update/delete stored procs operate within a transaction (via @@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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0