Thanks Aaron. Ive put my response under "Nik" below your comments.
1) Broken Authentication and session management
Most enterprise applications provide valid session management. However, if you need to, you can enforce login URLs per the ASM config guide:
Configuring login URLs to prevent forceful browsing
https://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/config_guide_asm_10_2_0/asm_security_policy.html
Nik - Will configuring Login URL's only be enough for protection against forceful browzing and broken Authentication
2) Insecure direct object reference
You can configure login URLs and/or application flows to ensure clients have successfully authenticated and/or follow an expected path through the application.
Nik - Will configuring Login URL's only be enough for protection against insecure direct object reference
3) Security Misconfiguration
Here's a suggested list of possible issues. Which are you trying to address?
https://www.owasp.org/index.php/Top_10_2010-A6
Nik- These issues were thrown up under "OWASP - Security Misconfiguration" during a scan. How can asm address these -
a) Alternative version of files detected - Possible to gather sensitive information about web application such as usernames , pwd, m/c name and/or sensitive file locations.Casue- Temporary files were left in production
b) Application test script detected - possible to download temp script files.Casue -Temporary files were left in production
Temp files were left in production environment and were downloadable.
c) Autocomplete html attribute not disabled for password field.
d) Compressed directory found - Its possible to retrieve code of server - side scripts exposing application logic. Casue - Insecure web app programming / config
4) Failure to restrict URL access
Again, as in 2, you can use login URLs and/or application flows to ensure clients have successfully authenticated and/or follow an expected path through the application. You can also use attack signatures and/or URLs to restrict which URLs clients can access.
Nik - Will configuring Login URL's only be enough for protection against Failure to restrict URL access.
Further , For restricting what URL clients can access , wouldnt applying a policy based on legitimate URLS be very overwhelming/time conmsuming to learn and apply ?
5) Insufficient transport layer protection
You can easily redirect all HTTP requests to HTTPS using LTM. You can also restrict which SSL ciphers clients are allowed to use when accessing an HTTPS virtual server:
https://devcentral.f5.com/wiki/iRules.RedirectOnWeakEncryption.ashx
Nik - OK
6) Unvalidated redirects and fowards
You can define valid redirects for specific parameter values either globally or per URL.
Nik - OK
7) SQL injection (this is believe is protected through attack signatures , in policy->blocking )
ASM provides very complete SQLi protection through character set restrictions and attack signatures.
Nik - OK
Nimbostratus
