Test Cases for Security Assessment Testing

Hi Guys, with a new security-related long blog with security test cases required while performing security testing on any web application.

Authentication

Much of this section is purely manual testing utilizing your common sense and eyes, does it look off? Should it be better? Point it out, tell your client if their password policy isn’t up to scratch!

• Test password quality rules — Look at how secure the site wants its passwords to be, is there a minimum/maximum? is there any excluded characters — ‘,<, etc — this might suggest passwords aren’t being hashed properly.

• Test for username enumeration — Do you get a different error if a user exists or not? Worth noting the application behavior if a user exists does the error change if they don’t?

• Test resilience to password guessing — Does the application lockout an account after x number of login attempts?

• Test password creation strength — Is there a minimum creation length? Is the policy ridiculous? e.g.“mustbebetween4and 8 characters passwords are not case sensitive” — should kick off alarm bells for most people!

• Test any account recovery function — Look at how an account can be recovered, are there methods in place to prevent an attacker changing the email without asking current user? Can the password be changed without knowing anything about the account? Can you recover to a different email address?

• Test any “remember me” function — Does the remember me function ever expire? Is there room for exploit-ability in cookies combined with other attacks?

• Test any impersonation function — Is it possible to pretend to be other users? Can session cookies be stolen and replayed? Does the application utilize anti-cross site request forgery102?

• Test username uniqueness — Can you create a username or is it generated for you? Is it a number that can be incremented? Or is it something the user knows and isn’t displayed on the application?

• Check for unsafe distribution of credentials — How are logins processed, are they sent over HTTP? Are details sent in a POST request or are they included in the URL (this is bad if they are, especially passwords)?

• Test for fail-open conditions — Fail-open authentication is the situation when the user authentication fails but results in providing open access to authenticated and secure sections of the web application to the end-user.

• Test any multi-stage mechanisms — Does the application utilize multi-steps, e.g. username->click next->password->login, can this be bypassed by visiting complete page after the username is entered? (similar to IDOR issues) — Session Management– How well are sessions handled, is there randomness to the session cookie? Are sessions killed in a reasonable time or do they last forever? Does the app allow multiple logins from the same user (is this significant to the app?). — Test tokens for meaning — What do the cookies mean?!

• Test tokens for predictability — Are tokens generated predictably or do they provide a sufficiently random value, tools to help with this are Burp Suite’s sequencer tool.

• Check for insecure transmission of tokens — This lies the same way as insecure transmission of credentials, are they sent over HTTPS? are they included in URL? Can they be accessed by JavaScript? Is this an Issue?

• Check for disclosure of tokens in logs — Are tokens cached in browser logs? Are they cached server-side? Can you view this? Can you pollute logs by setting custom tokens?

• Check to map of tokens to sessions — Is a token tied to a session, or can it be re-used across sessions?

• Check session termination — is there a time-out?

• Check for session fixation — Can an attacker hijack a user’s session using the session token/cookie?

• Check for cross-site request forgery — Canauthenticatedactionsbeperformedwithinthecontextoftheapplicationfromother websites?

• Check cookie scope — Is the cookie scoped to the current domain or can it be stolen, what are the flags set> is it missing secure or http-only? This can be tested by trapping the request in burp and looking at the cookie.

• Understand the access control requirements — How do you authenticate to the application, could there be any flaws here?

• Test effectiveness of controls, using multiple accounts if possible

• Test for insecure access control methods (request parameters, Referrer header, etc)

Input Validation

• Fuzz all request parameters — Look at what you’re dealing with, are parameters reflected? Is there a chance of open redirection?

• Test for SQL injection — Look at if a parameter is being handled as SQL, don’t automate this off the bat as if you don’t know what a statement is doing you could be doing DROP TABLES.

• Identify all reflected data

• Test for reflected cross-site scripting (XSS)

• Test for HTTP header injection

• Test for arbitrary redirection

• Test for stored attacks

• Test for OS command injection

• Test for path traversal

• Test for JavaScript/HTML injection — similar to XSS

• Test for file inclusion — both local and remote

• Test for SMTP injection

• Test for SOAP injection — can you inject SOAP envelopes, or get the application to respond to SOAP, this ties into XXE attacks too.

• Test for LDAP injection — not so common anymore but look for failure to sanitize input leading to possible information disclosure

• Test for XPath injection -can you inject XML that is reflected or causes the application to respond in a weird way?

• Test for template injection-does the application utilizes a templating language that can enable you to achieve XSS or worse remote code execution? — There is a tool for this, automated template injection with Sqlmap

• Test for XXE injection — does the application respond to external entity injection?

Application/Business Logic

This type of test cases also play an important role in security testing while other typed test cases can be automated with any tool, but application/business logic test cases are too difficult to automate with tool because every application’s logic is different to others.

• Identify the logic attack surface — What does the application do, what is the most value, what would an attacker want to access?

• Test transmission of data via the client — Is there a desktop application or mobile application, does the transferal of information vary between this and the web application

• Test for reliance on client-side input validation– Does the application attempt to base its logic on the client-side, for example, do forms have a maximum length client side that can be edited with the browser that is simply accepted as true?

• Test any thick-client components (Java, ActiveX, Flash) — Does the application utilize something like Java, Flash, ActiveX or Silverlight? can you download the applet and reverse engineer it?

• Test multi-stage processes for logic flaws — Can you go from placing an order straight to delivery thus bypassing payment? or a similar process?

• Test handling of incomplete input — Can you pass the application dodgy input and does it process it as normal, this can point to other issues such as RCE & XSS.

• Test trust boundaries — What is a user trusted to do, can they access admin aspects of the app?

• Test transaction logic

• Can you pay ££0.00 for an item that should be ££1,000,000 etc?

• Test for Indirect object references(IDOR)

• Can you increment through items, users. uuids or other sensitive info?

Application Infrastructure

• Test segregation in shared infrastructures/ virtual hosting environments

• Test segregation between ASP-hosted applications

• Test for web server vulnerabilities — this can be tied into port scanning and infrastructure assessments

• Default credentials

• Default content

• Dangerous HTTP methods

• Proxy functionality

Miscellaneous tests

• Check for DOM-based attacks — open redirection, cross-site scripting, client-side validation.

• Check for frame injection, frame busting (can still be an issue)

• Check for local privacy vulnerabilities

• Persistent cookies

• Weak cookie options

• Caching

• Sensitive data in URL parameters

• Follow up any information leakage

• Check for weak SSL ciphers

• HTTP Header analysis — look for lack of security headers such as — Content Security Policy (CSP) — HTTP Strict Transport Security (HSTS) — X-XSS-Protection — X-Content-Type-Options — HTTP Public Key Pinning

Hopefully, this has been an insight into what to look for and how it can be looked for. Your own methodology is up to you, it is your responsibility to test and then act/report on what you’ve found.