Skip to content

Application test case brainstorming

Jump to bottom
Randy Gingeleski edited this page Apr 20, 2018 · 4 revisions

Behavior-driven security tests – application test case brainstorming

Web server does not leak revealing information about itself

  • Responses should not have a “Server” header
  • Responses should not have an “X-Powered-By” header
  • Responses should not have an “X-Generator” header

Web application responses do not leak revealing information

  • Response HTML should not have with “name” attribute as “generator” (ignore case)
    • <meta name="generator" content="WordPress 3.9.2" />

Account lockout occurs after 5 login attempts with bad credentials

  • Can leverage Selenium + headless Chrome
  • After 5 bad login attempts, the account should be locked
  • A JavaScript alert appears after 3 bad attempts to warn of forthcoming account lock
  • When the account is locked, a JavaScript alert states the account has been locked

Web application should not accept arbitrary HTTP request methods

  • Send “CATS” or “JEFF” requests and make sure the application denies

Web application should not accept HTTP request methods other than GET or POST

  • Could chalk this up to an organizational requirement
  • Send HEAD, PUT, DELETE, TRACE, and OPTIONS requests to try and make the application do bad stuff

Application responses have proper HTTP Strict Transport Security configured

  • Check for response header “Strict-Transport-Security”
    • Value could be max-age=31536000; includeSubDomains

Testing role definitions

  • Can leverage Selenium + headless Chrome
  • Thinking we will have multiple roles (say 3 at least)
  • Have an endpoint all roles can access
  • But the information displayed to them is different
  • Also, how the information is presented should ideally be rendered by JavaScript
  • This provides a good excuse to use the browser to render then check the data displayed

Testing secure registration – user ID

  • Maybe user has a profile page which reveals their user ID (for internal use)
  • Make sure ID assigned is random (to prevent enumeration attacks?)
  • Could also have registration send an email to verify user’s address
  • But we could mock out, for our tests, the class that sends that email
    • Sets some kind of flag for the test to read instead of actually sending

Testing secure registration – username harvesting

  • Make sure registration page gives no inclination that a username is already taken
  • When the request is made, the response should contain an error to this effect
  • Along these lines, the registration page should also include a captcha
  • However we’d probably do best to mock this out for our testing (i.e. mock the captcha class so when the input is “4444” it accepts or something

Testing secure registration – captcha

  • See above
  • Maybe the captcha test is a separate scenario

Testing secure registration – password policy

  • Can maybe leverage Selenium + headless Chrome (see last bullet)
  • We’ll pretend our fictional organization has a global password complexity policy from their IT Security department
  • At the registration view we can test that this is enforced
  • Seems plausible there would be both client-side protection then server-side protection
  • Obviously only server-side is what counts, but as an excuse to do Selenium + Chrome things, maybe we test client-side too?

Web application should not be susceptible to user account harvesting

  • Can leverage Selenium + headless Chrome
  • Ensure rendered responses match for (A) valid username and bad password then (B) invalid username and made-up password
  • Response status code, headers, then rendered HTML / page source

Authentication credentials are protected by TLS

Session cookie has “HTTPOnly” and “Secure” attributes enabled

  • See above… if can’t get HTTPS going on localhost we’ll have to just test “HTTPOnly”
  • Can leverage Selenium + headless Chrome
  • Instead of just testing that “HTTPOnly” is set on the response “Set-Cookie”, can assert on the attribute in the Selenium session
  • Can also load some proof-of-concept HTML from “different domain” (different localhost port?) that has JavaScript which tries to do CSRF

Session cookie changes with every request

  • Maybe our fictional organization has an ITSD requirement that “high” ASRL web apps must change/update their session cookie every request
  • Can test response “Set-Cookie” is changing the session one
  • Can then try sending old session cookie to make sure it kicks us out
  • Overall idea here is session cookies are good for single requests only

Attempt SQL injection on login form

Attempt SQL injection on "Forgot password" page

Check "Content-Type-Options" response header

  • Should be set to "no-sniff"

Ensure an appropriate "Content-Type" response header is set

  • This will vary by page and resource

Check cache control response headers

Check idle session timeout

  • Pretend fictional org has ITSD idle session timeout requirements
  • Hoping we can manipulate time in some way so this is not a long test case
  • Maybe mock class with this value (length of time) in it

Check absolute session timeout

  • Pretend fictional org has ITSD absolute session timeout requirements
  • See time manipulation notes above

Check "X-Frame-Options" response header

Test against CSRF

Check "X-XSS-Security" response header

Test logout functionality properly invalidates the session

Check reflected XSS

  • Maybe there's a search functionality to the app... something that plausibly "reflects" an input
  • Ensure fields stored there are properly encoded and/or whitelist characters

Check stored XSS

  • Maybe user has a public profile
  • Ensure fields stored there are properly encoded and/or whitelist characters

Check against XML external entity (XXE) injection

  • This is in the 2017 OWASP Top 10 that we're mapping test categories to, so should try to hit this
Clone this wiki locally