Abuse Case Testing

Meta: @story authentication

Scenario: Passwords should be case sensitive
Meta: @id auth_case @cwe-178-auth
Given a new browser instance
And the default user from: users.table
When the case of the password is changed
And the user logs in
Then the user is not logged in

@Test
public void password_should_be_case_sensitive() {
    webAppSteps.loginFromTable(this.credentialsTable);
    webAppSteps.loginSucceeds();
    webAppSteps.loginWithWrongCasedPassword();
    webAppSteps.loginFromFreshPage();
    webAppSteps.loginFails();
}

Meta: @story http_headers

Scenario: Restrict other sites from placing it in an iframe in order to prevent ClickJacking attacks
Meta: @id headers_xframe_options @skip
Given a new browser instance
When the secure base Url is accessed and the HTTP response recorded
Then the X-Frame-Options header is either SAMEORIGIN or DENY

Scenario: Enable built in browser protection again Cross Site Scriping
Meta: @id headers_xss_protection @skip
Given a new browser instance
When the secure base Url is accessed and the HTTP response recorded
Then the HTTP X-XSS-Protection header has the value: 1; mode=block

Scenario: Force the use of HTTPS for the base secure Url
Meta: @id headers_sts @skip
Given a new browser instance
When the secure base Url is accessed and the HTTP response recorded
Then the Strict-Transport-Security header is set

Scenario: Restrict HTML5 Cross Domain Requests to only trusted hosts
Meta: @id headers_cors @skip
Given a new browser instance
When the secure base Url is accessed and the HTTP response recorded
Then the Access-Control-Allow-Origin header must not be: *

Scenario: Enable anti-MIME sniffing prevention in browsers
Meta: @id headers_nosniff @skip
Given a new browser instance
When the secure base Url is accessed and the HTTP response recorded
Then the HTTP X-Content-Type-Options header has the value: nosniff

@Test
public void http_security_headers_should_be_set () {
    webAppSteps.enableLoggingDriver();
    webAppSteps.clearProxy();
    webAppSteps.openBaseSecureUrl();
    webAppSteps.recordFirstHarEntry();
    webAppSteps.checkIfHSTSHeaderIsSet();
    webAppSteps.checkIfXFrameOptionsHeaderIsSet(Constants.SAMEORIGIN,Constants.DENY);
    webAppSteps.checkHeaderValue(Constants.XXSSPROTECTION, Constants.XXSSPROTECTION_VALUE);
    webAppSteps.checkThatAccessControlAllowOriginIsNotStar(Constants.STAR);
    webAppSteps.checkHeaderValue(Constants.XCONTENTTYPEOPTIONS, Constants.NOSNIFF);
}

Scenario: Users can view restricted resources for which they are authorised
Meta: @id config_authorised_resources
Given a new browser instance
And the browser is configured to use an intercepting proxy
And the proxy logs are cleared
And the login page
And the username <username>
And the password <password>
When the user logs in
And the proxy logs are cleared
And the HTTP requests and responses on recorded
And they access the restricted resource: <method>
Then the string: <sensitiveData> should be present in one of the HTTP responses
Examples:
tables/authorised.resources.table


Scenario: Users must not be able to view resources for which they are not authorised
Meta: @id access_control_restricted @cwe-639
Given the access control map for authorised users has been populated
And a new browser instance
And the username <username>
And the password <password>
And the login page
When the user logs in
And the previously recorded HTTP Requests for <method> are replayed using the current session ID
Then the string: <sensitiveData> should not be present in any of the HTTP responses
Examples:
tables/unauthorised.resources.table