1

I am currently planning security testing procedures within an API gateway. We want to define in advance what we expect to be covered on the security level.

Scanning REST APIs (see http://docs.w3af.org/en/latest/scan-rest-apis.html)

  • SQL Injection
  • Command Injection
  • Header Injection
  • Cross-site scripting – reflected.
  • Cross-site scripting – stored.
  • Cross-site scripting – dom based.
  • Missing security headers
  • Sensitive Information disclosure in response headers
  • Sensitive Information disclosure in error messages
  • Missing Server Side input Validation
  • Unwanted use of HTTP methods
  • Improper HTTP Response

Vulnerabilities Test

  • Login (Anonymous user )
  • Login (Registered User)
  • UI (Authentification)
  • Weak Session ID Test
  • Sensitive Information Disclosure - phpinfo.php Test
  • Weak Password Policy Test
  • Verb Tempering Test
  • Direct Dynamic Code Execution - Eval Injection
  • Cross site Scripting - reflected
  • SQL Injection
  • Command Injection.
  • Header Injection.
  • Cross-site scripting – stored.
  • Cross-site scripting – dom based.
  • Missing security headers.
  • Malicious JS script execution.
  • Using components with known vulnerabilities.
  • Jquery Vulnerabilities
  • Angularjs Vulnerabilities.
  • Bootstrap Vulnerabilities
  • Sensitive Information disclosure in response headers.
  • Sensitive Information disclosure in error messages.
  • Missing Server Side Validation.
  • Javascript Dynamic Code Execution.
  • Sensitive Data Exposure

Questions:

Especially the factor penetration tests in the REST API area (here in the special gateway) is somehow not yet completely clarified on our site. Therefore we still need more information here.

Are the approaches we have given here sufficient? Here there are approaches to implement this on the one hand via a tooling correspondingly via a Jenkins automation.

The projects that are behind the API gateway are to be tested in the V area. This will also be done by an appropriate tooling that meets our requirements.

But are there points, rules, or approaches we have not yet thought about in this area?

  • 1
    They look good, you could add IDOR, XXE (if you even have that), dirbust for sensitive files e.g. config.ini, outdated vulnerable 3rd party components. – Raimonds Liepiņš Aug 29 at 7:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.