CAST AIP coverage for OWASP Top 10 - 2017
For more details on each vulnerability, you can check the OWASP website.
| OWASP Vulnerability |
Description |
CAST AIP Coverage |
|
A1-Injection
|
Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
|
Pre-built rule in CAST AIP – check CAST AIP OWASP Coverage - Detailed Description for list of rules and more details.
|
|
A2-Broken Authentication and Session Management
|
Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.
|
Pre-built rule in CAST AIP
CAST supports the application/security architect by providing information about application structure, allowing the definition of custom rules using architecture checker, and the tracking and control of these rules in subsequent application development.
|
|
A3-Sensitive Data Exposure
|
Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.
|
Sensitive cryptography routines should be reviewed by a domain expert at the application-architecture level to ensure best practices are followed.
CAST supports with pre build rules and with application/security architect by providing information about application structure, allowing the definition of custom rules using architecture checker, and the tracking and control of these rules in subsequent application development.
|
|
A4-XML External Entities (XXE)
|
Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.
|
CAST supports the application/security architect by providing information about application structure, allowing the definition of custom rules using architecture checker, and the tracking and control of these rules in subsequent application development.
|
|
A5-Broken Access Control
|
Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users' accounts, view sensitive files, modify other users' data, change access rights, etc.
|
CAST supports the application/security architect by providing information about application structure, allowing the definition of custom rules using architecture checker, and the tracking and control of these rules in subsequent application development.
|
|
A6-Security Misconfiguration
|
Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.
|
CAST supports with pre-built rules and the application/security architect by providing information about application structure, allowing the definition of custom rules developed with SDK or architecture checker,
Application security policies should be reviewed by a domain expert at the application-architecture level to ensure best practices are followed.
|
|
A7-Cross-Site Scripting (XSS)
|
XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
|
Pre-built rule in CAST AIP – check CAST AIP OWASP Coverage - Detailed Description for list of rules and more details.
|
|
A8-Insecure Deserialization
|
Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.
|
Cast provides to create custom rules using SDK, CAST supports the application/security architect by providing information about application structure, allowing the definition of custom rules using architecture checker, and the tracking and control of these rules in subsequent application development.
|
|
A9-Using Components with Known Vulnerabilities
|
Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defences and enable a range of possible attacks and impacts.
|
A complete inventory of the third parties (libraries, frameworks and tools) used by a project should be in place. Versions should be kept up-to-date, and current versions should be monitored for security weaknesses announcements.
These vulnerabilities are not possible to find using static analysis. CAST has integrations with vendors in the SCA space who track known vulnerabilities, to display them alongside CAST AIP findings.
|
|
A10-Insufficient Logging and monitoring
|
Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
|
These vulnerabilities are not possible to find using static analysis. CAST Consultant during the assessment would provide the feedback and will display them alongside CAST AIP findings.
|
CAST AIP coverage for OWASP Top 10 - 2013
For more details on each vulnerability, you can check the OWASP website.
| OWASP Vulnerability |
Description |
CAST AIP Coverage |
|
A1-Injection
|
Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted
data is sent to an interpreter as part of a command or query. The attacker’s
hostile data can trick the interpreter into executing unintended commands
or accessing data without proper authorization.
|
Pre-built rule in CAST AIP – check
CAST AIP OWASP Coverage – Detailed Description for list of rules and
more details.
|
|
A2-Broken Authentication and Session Management
|
Application functions related to authentication and session management
are often not implemented correctly, allowing attackers to compromise passwords,
keys, or session tokens, or to exploit other implementation flaws to assume
other users’ identities.
|
This is planned for a future release
|
|
A3-Cross-Site Scripting (XSS)
|
XSS flaws occur whenever an application takes untrusted data and sends
it to a web browser without proper validation or escaping. XSS allows attackers
to execute scripts in the victim’s browser which can hijack user sessions,
deface web sites, or redirect the user to malicious sites.
|
Pre-built rule in CAST AIP – check
CAST AIP OWASP Coverage – Detailed Description for list of rules and
more details.
|
|
A4-Insecure Direct Object References
|
A direct object reference occurs when a developer exposes a reference
to an internal implementation object, such as a file, directory, or database
key. Without an access control check or other protection, attackers can
manipulate these references to access unauthorized data.
|
As described in the OWASP document these vulnerabilities are impossible
to check using source code analysis
|
|
A5-Security Misconfiguration
|
Good security requires having a secure configuration defined and deployed
for the application, frameworks, application server, web server, database
server, and platform. Secure settings should be defined, implemented, and
maintained, as defaults are often insecure. Additionally, software should
be kept up to date.
|
Application security policies should be reviewed by a domain expert at the application-architecture level to ensure best practices are followed. CAST supports the application/security architect by providing information about application structure, allowing the definition of custom rules using architecture checker, and the tracking and control of these rules in subsequent application development.
|
|
A6-Sensitive Data Exposure
|
Many web applications do not properly protect sensitive data, such as
credit cards, tax IDs, and authentication credentials. Attackers may steal
or modify such weakly protected data to conduct credit card fraud, identity
theft, or other crimes. Sensitive data deserves extra protection such as
encryption at rest or in transit, as well as special precautions when exchanged
with the browser.
|
Sensitive cryptography routines should be reviewed by a domain expert at the application-architecture level to ensure best practices are followed. CAST supports the application/security architect by providing information about application structure, allowing the definition of custom rules using architecture checker, and the tracking and control of these rules in subsequent application development.
|
|
A7-Missing Function Level Access Control
|
Most web applications verify function level access rights before making
that functionality visible in the UI. However, applications need to perform
the same access control checks on the server when each function is accessed.
If requests are not verified, attackers will be able to forge requests in
order to access functionality without proper authorization.
|
AIP is currently able to check that access control systems are in place for some presentation frameworks, such as Struts.
|
|
A8-Cross-Site Request Forgery (CSRF)
|
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP
request, including the victim’s session cookie and any other automatically
included authentication information, to a vulnerable web application. This
allows the attacker to force the victim’s browser to generate requests the
vulnerable application thinks are legitimate requests from the victim.
|
Pre-built rule in CAST AIP – check
CAST AIP OWASP Coverage – Detailed Description for list of rules and
more details.
|
|
A9-Using Components with Known Vulnerabilities
|
Components, such as libraries, frameworks, and other software modules,
almost always run with full privileges. If a vulnerable component is exploited,
such an attack can facilitate serious data loss or server takeover. Applications
using components with known vulnerabilities may undermine application defences
and enable a range of possible attacks and impacts.
|
A complete inventory of the third parties (libraries, frameworks and tools) used by a project should be in place. Versions should be kept up-to-date, and current versions should be monitored for security weaknesses announcements. These vulnerabilities are not possible to find using static analysis. CAST has integrations with vendors in the SCA space who track known vulnerabilities, to display them alongside CAST AIP findings.
|
|
A10-Unvalidated Redirects and Forwards
|
Web applications frequently redirect and forward users to other pages
and websites, and use untrusted data to determine the destination pages.
Without proper validation, attackers can redirect victims to phishing or
malware sites, or use forwards to access
|
As described in the OWASP document these vulnerabilities are impossible
to check using source code analysis
|
CAST AIP coverage for CWE Top 25
All the categories, rules, and related description are referenced from CWE/SANS
and CWE/SANS Top 25 Most Dangerous
Software Errors.
Insecure Interaction between Components
These weaknesses are related to insecure ways in which data is sent and received
between separate components, modules, programs, processes, threads, or systems.
| Rank |
CWE ID |
Name |
Recommendation/Mitigation/Comments |
Coverage with CAST AIP |
|
[1]
|
CWE-89
|
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
|
Checking for SQL Injection by
|
Pre-built rule in AIP – 2663 - Avoid SQL injection vulnerabilities
|
|
[2]
|
CWE-78
|
Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
|
Checking for OS Command Injection
|
Pre-built rule in AIP – 2661 - Avoid OS command injection vulnerabilities
|
|
[4]
|
CWE-79
|
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
|
Checking for Cross-site scripting
|
Pre-built rule in AIP – 2284 - Avoid cross-site scripting vulnerabilities
|
|
[9]
|
CWE-434
|
Unrestricted Upload of File with Dangerous Type
|
Input Validation
|
In CAST AIP 8.0, we trigger this rule via PATH Manipulation. Extend the following existing rules –
- 2437 - Avoid non-standard file extensions
- 2659 - Avoid file path manipulation vulnerabilities
- 2660 - Avoid XPath injection vulnerabilities
|
|
[12]
|
CWE-352
|
Cross-Site Request Forgery (CSRF)
|
Ensure that application is free of cross-site scripting issues (CWE-79), because most CSRF defences can be bypassed using attacker-controlled script.
|
Pre-built rule in AIP – 2284 - Avoid cross-site scripting vulnerabilities
|
|
[22]
|
CWE-601
|
URL Redirection to Untrusted Site ('Open Redirect')
|
Checking for Cross-site scripting
|
Pre-built rule in AIP – 2284 - Avoid cross-site scripting vulnerabilities
|
Risky resource management
The weaknesses in this category are related to ways in which software does not properly manage the creation, usage, transfer, or destruction of important system resources.
| Rank |
CWE ID |
Name |
Recommendation/Mitigation/Comments |
Coverage with CAST AIP |
|
[3]
|
CWE-120
|
Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
|
Perform input validation on any numeric input by ensuring that it
is within the expected range. Enforce that the input meets both the
minimum and maximum requirements for the expected range.
|
This rule is handled through a combination of existing quality rules around memory handling listed below –
- 7794 - Avoid using getopt() function,
- 7988 - Never use sprintf() function or vsprintf() function
- Never perform C cast between incompatible class pointers
- Avoid using static_cast on class/struct pointers
|
|
[13]
|
CWE-22
|
Improper Limitation of a Pathname to a Restricted Directory ('Path
Traversal')
|
Checking for file path manipulation
|
Pre-built rule in AIP – 7752 - Avoid file path manipulation vulnerabilities
|
|
[14]
|
CWE-494
|
Download of Code Without Integrity Check
|
Check Download Code Integrity
|
We manage this using Input Validation approach –
|
|
[16]
|
CWE-829
|
Inclusion of Functionality from Untrusted Control Sphere
|
When the set of acceptable objects, such as filenames or URLs, is
limited or known, create a mapping from a set of fixed input values
(such as numericIDs) to the actual filenames or URLs, and reject all
other inputs.
|
This is handled by checking every internet library for vulnerability and maintaining a whitelist. Normally we can check the HTML code and parse the URL to verify the domain. Extend the existing rule 2660 - Avoid XPath injection vulnerabilities
|
|
[18]
|
CWE-676
|
Use of Potentially Dangerous Function
|
Checking for programming best practices
|
Pre-built rule in AIP –
|
|
[20]
|
CWE-131
|
Incorrect Calculation of Buffer Size
|
Perform input validation on any numeric input by ensuring that it
is within the expected range. Enforce that the input meets both the
minimum and maximum requirements for the expected range.
|
This is handled through a combination of existing quality rules listed below:
|
|
[23]
|
CWE-134
|
Uncontrolled Format String
|
Checking for programming best practices
|
Checking for programming best practices
Pre-built inCAST AIP rule. Extend the following existing rules –
- 8098 - Uncontrolled format string
|
|
[24]
|
CWE-190
|
Integer Overflow or Wraparound
|
Perform check on any numeric input by ensuring that it is within the
expected range. Enforce that the input meets both the minimum and maximum
requirements for the expected range.
|
These rules require using DF with Arithmetics. This will be handled by extending the existing rule, 2282 - Avoid using getopt() function
|
Porous Defences
The weaknesses in this category are related to defensive techniques that are
often misused, abused, or just plain ignored.
| Rank |
CWE ID |
Name |
Recommendation/Mitigation/Comments |
Coverage with CAST AIP |
|
[5]
|
CWE-306
|
Missing Authentication for Critical Function
|
avoid implementing custom authentication routines and consider using
authentication capabilities as provided by the surrounding framework,
operating system, or environment.
|
This requirement is achieved using DF and User input security and extending existing rules –
|
|
[6]
|
CWE-862
|
Missing Authorization
|
Users should not be able to access any unauthorized functionality
or information by simply requesting direct access to that page.
|
This requirement will be achieved using DF and User input security
and extending existing rules –
|
|
[8]
|
CWE-311
|
Missing Encryption of Sensitive Data
|
Periodically ensure that you aren't using obsolete cryptography.
Avoid using old encryption techniques using MD4, MD5, SHA1, DES, and
other algorithms that were once regarded as strong.
|
Checking of encryption can be handled using custom rules that check for the use of known encryption functions and/or libraries -
|
|
[10]
|
CWE-807
|
Reliance on Untrusted Inputs in a Security Decision
|
Consider getcookies as unsafe
|
Pre-built rule in AIP – 2284 - Avoid cross-site scripting vulnerabilities
|
|
[11]
|
CWE-250
|
Execution with Unnecessary Privileges
|
Checking for privileges being appropriately implemented based on
the scenario/use case. Perform extensive input validation and canonicalization
to minimize the chances of introducing a separate vulnerability.
|
This is more linked to dynamic analysis and not directly handled by CAST AIP today. We can extend existing rules to cover part of this requirement –
|
|
[15]
|
CWE-863
|
Incorrect Authorization
|
Consider getcookies as unsafe
|
Pre-built rule in AIP – 2284 - Avoid cross-site scripting vulnerabilities
|
|
[17]
|
CWE-732
|
Incorrect Permission Assignment for Critical Resource
|
Path manipulation
|
Pre-built rule in AIP – 2659 - Avoid file path manipulation vulnerabilities
|
|
[19]
|
CWE-327
|
Use of a Broken or Risky Cryptographic Algorithm
|
Validating encryption algorithms
|
This will be addressed by creating a blacklist of functions considered risky or broken (Handle via maintaining blacklist of well known and crypto algorithms) and applying custom architectural rules to check for the use of appropriate functions.
|
|
[21]
|
CWE-307
|
Improper Restriction of Excessive Authentication Attempts
|
Check login implementation
|
This will be handled by extending the following existing rules –
|
|
[25]
|
CWE-759
|
Use of a One-Way Hash without a Salt
|
Checking for programming best practices. Best practice, always use
initialises that contain salt for Hash. Instead of calling Hashlib with
just one parameter use additional parameters for salt.
|
This will be addressed by blacklisting methods that does not contain
the good initialization parameters. Extend the following existing rules
–
|
CAST AIP coverage for CISQ Security
For more details on each vulnerability, you can check the OWASP website.
| CISQ Security Identifier |
Description |
CAST AIP Coverage |
|
ASCSM-CWE-22
|
Improper path traversal - Remove instances where a user input is ultimately used in a file path creation statement, without any sanitization (based on a list of vetted sanitization functions, methods, procedures, stored procedures, sub-routines, etc.) of the user input value between the user input and the statement.
|
Pre-built rule in CAST AIP – check CAST AIP OWASP Coverage - Detailed Description for list of rules and more details.
|
|
ASCSM-CWE-78
|
OS command injection - Remove instances where a user input is ultimately used to execute an OS command, without any sanitization (based on a list of vetted sanitization functions, methods, procedures, stored procedures, sub-routines, etc.) of the user input value between the user input and the statement.
|
Pre-built rules in CAST AIP – check CAST AIP OWASP Coverage - Detailed Description for list of rules and more details.
|
|
ASCSM-CWE-79
|
Cross-site scripting - Remove instances where a user input is ultimately displayed to the user, without any sanitization (based on a list of vetted sanitization functions, methods, procedures, stored procedures, sub-routines, etc.) of the user input value between the user input and the statement.
|
Pre-built rules in CAST AIP – check CAST AIP OWASP Coverage - Detailed Description for list of rules and more details.
|
|
ASCSM-CWE-89
|
SQL injection - Remove instances where a user input is ultimately used in a SQL statement, without any sanitization (based on a list of vetted sanitization functions, methods, procedures, stored procedures, sub-routines, etc.) of the user input value between the user input and the statement.
|
Pre-built rules in CAST AIP – check CAST AIP OWASP Coverage - Detailed Description for list of rules and more details.
|
|
ASCSM-CWE-99
|
Unsanitized user input used to access a named resource - Remove instances where a user input is ultimately used to access a resource by name, without any sanitization (based on a list of vetted sanitization functions, methods, procedures, stored procedures, sub-routines, etc.) of the user input value between the user input and the statement.
|
Pre-built rules in CAST AIP
|
|
ASCSM-CWE-120
|
Buffer overflow - Remove instances where the content of the first buffer is moved into the content of the second buffer while their allocated sizes are incompatible
|
Pre-built rules in CAST AIP
|
|
ASCSM-CWE-129
|
Unchecked array index range - Remove instances where a user input is ultimately used in a ‘Read’ or ‘Write’ access to an array, without any range check between the user input and the array access.
|
CAST supports the application/security architect by providing information about application structure, allowing the definition of custom rules using architecture checker, and the tracking and control of these rules in subsequent application development.
|
|
ASCSM-CWE-134
|
Improper format string neutralization - Remove instances where a user input is ultimately used in a formatting statement, without any sanitization (based on a list of vetted sanitization functions, methods, procedures, stored procedures, sub-routines, etc.) of the user input value between the user input and the statement.
|
Pre-built rules in CAST AIP
|
ASCSM-CWE-252-resourse |
Unchecked return parameter from resource handling operations - Remove instances where the function, method, procedure, stored procedure, sub-routine, etc. reads, writes, or manages an external resource, yet the value of the return code is not checked anywhere |
Custom defined rules |
ASCSM-CWE-327 |
Unchecked return parameter from resource handling operations - Remove instances where the application uses a cryptographic list which is not part of the list of vetted cryptographic libraries. |
Pre-built rules in CAST AIP |
ASCSM-CWE-396 |
Catch of overly broad exception types - Remove instances where the function, method, procedure, stored procedure, sub-routine, etc. contains a catch which declares to catch an exception whose type is part of a list of overly broad exception types |
Pre-built rules in CAST AIP |
ASCSM-CWE-397 |
Throw of overly broad exception types - Remove instances where the function, method, procedure, stored procedure, sub-routine, etc. throws an exception whose type is part of a list of overly broad exception types |
Pre-built rules in CAST AIP |
ASCSM-CWE-434 |
Unsanitized user input in file upload statement - Remove instances where a user input is ultimately used in a file upload statement, without any sanitization (based on a list of vetted sanitization functions, methods, procedures, stored procedures, sub-routines, etc.) of the user input value between the user input and the statement. |
Pre-built rules in CAST AIP |
ASCSM-CWE-456 |
Uninitialized data element - Remove instances where a variable, field, member, etc. is declared, then is evaluated without ever being initialized prior to the evaluation. |
Pre-built rules in CAST AIP |
ASCSM-CWE-606 |
Unchecked input in loop condition - Remove instances where a user input is ultimately used in the loop condition statement, without any range check between the user input and the loop statement. |
Custom defined rule using SDK |
ASCSM-CWE-667 |
Improper locking of shared resources - Remove instances where the shared variable, field, member, etc., is accessed outside a critical section of the application. |
Custom defined rule using architect checker |
ASCSM-CWE-672 |
Access to released or expired resources - Remove instances where the platform resource (messaging, lock, file, stream, etc.) is deallocated using its unique resource handler which is used later within the application to try and access the resource. |
Pre-built rules in CAST AIP |
ASCSM-CWE-681 |
Incompatible numeric type conversion - Remove instances where a variable, field, member, etc. is declared with a numeric type, and then is updated with a value from a second numeric type that is incompatible with the first numeric type |
Pre-built rules in CAST AIP |
ASCSM-CWE-772 |
Unreleased resource - Remove instances where a variable, field, member, etc. is declared with a numeric type, and then is updated with a value from a second numeric type that is incompatible with the first numeric type |
Pre-built rules in CAST AIP |
ASCSM-CWE-789 |
Unchecked range of user input to a buffer - Remove instances where a user input is ultimately used in a ‘Read’ or ‘Write’ access to a buffer, without any range check between the user input and the buffer access. |
Pre-built rules in CAST AIP |
ASCSM-CWE-798 |
Hard‐coded credentials for remote resources - Remove instances where a variable, field, member, etc., is initialized with a hard-coded literal value, and ultimately used to access a remote resource. |
Pre-built rules in CAST AIP |
ASCSM-CWE-835 |
Infinite recursion - Remove instances where a recursive function, method, procedure, stored procedure, sub-routine, etc., has no execution path to exit the recursion |
Pre-built rules in CAST AIP |
Detailed Notes on Specific OWASP Rules
All the rules and related description are referenced from OWASP.
OWASP 2013 - A1 – Injection Flaws
"Injection flaws, particularly SQL injection, are common in web applications.
There are many types of injections: SQL, LDAP, XPath, XSLT, HTML, XML, OS command
injection and many more.Injection occurs when user-supplied data is sent
to an interpreter as part of a command or query. Attackers trick the interpreter
into executing unintended commands via supplying specially crafted data."
CAST AI Platform integrates a User Input Security Analyzer based on dataflow
technology. The Dataflow User Input Security Analyzer is a technology embedded
in the code analyzer that uses tainted variable analysis and tracks input data thru
out the source code to find a path where the input data is sent to a target server
without prior sanitization / encoding.
The User Input Security Analyzer offers directly supports the following type
of injection flaws grouped into the technical criteria metric called "Secure
Coding - Input Validation":
- SQL injection flaws
- LDAP injection flaws
- OS command injection flaws
- XPath injection flaws
- File path manipulation flaws
The User Input Security Analyzer can be customized to specific need interactively
to add specific sanitization, input or target methods for a given type of flaw.
The Dataflow User Input Security Analyzer offer manager and developers the view
of the precise path(s) where the vulnerability exist in a call path view directly
in the CAST dashboards.
In addition to the dataflow searched quality rules, CAST AI Platform provides
out of the box the following framework based rules also grouped into the technical
criteria metric called "Secure Coding - Input Validation":
- ASP.NET: Always validate user input with Request variables
- Struts Validator: Avoid action mappings validator turned off
- Struts Validator: Avoid Form Field without Validator
- Struts Validator: Avoid multiple validation form with the same name
- Struts Validator: Avoid unused validation form
- Struts Validator: Avoid Validator field without Form Field
- Struts Validator: Enable Struts Validator plugin
- Struts Validator: Form Bean must extend Validator Class
- Struts Validator: Validator form validate() method must call super.validate()
For applications following the OWASP recommendation to implement object relational
mapping (ORM) libraries such as Hibernate, CAST provides a specific rule that checks
that only Hibernate is used to access the database:
- Hibernate: Use only Hibernate API to access to the database
CAST provides also 13 rules to check that Hibernate architecture & performance
best practices are in place.
OWASP 2013 - A3 – Cross Site Scripting (XSS)
"Cross-site scripting, better known as XSS, is in fact a subset of HTML injection.
XSS is the most prevalent and pernicious web application security issue. XSS flaws
occur whenever an application takes data that originated from a user and sends it
to a web browser without first validating or encoding that content."
Being a special form of injection, a part of the solution to get rid of the XSS
threat comes from checking the protection in place for A2 Injection Flaws (see A2).
Indeed, beside A2 protection (validation of all incoming data), the OWASP Top Ten
document recommends the "appropriate encoding of all output data".
CAST supports checking that using the same technology as for Injection Flaws:
dataflow and tainted variable analysis to track input data thru out the source code
in order find a path where the input data is sent back to the user without prior
sanitization / encoding. The User Input Security Analyzer offers directly supports
Cross-Site Scripting flaws that can be found in the technical criteria metric called
"Secure Coding - Input Validation". As for A1-Injection flaws,
the user can customize interactively the analysis to meet specific needs: adding
specific sanitization, input or target methods for a given type of flaw is done
directly thru the GUI. XSS results are displayed in the dashboard which offers the
view of precise path(s) where the vulnerability exist in a call path view directly
in CAST AD Dashboard.
OWASP 2013 - A8 – Cross-Site Request Forgery (CSRF)
"A CSRF attack forces a logged-on victim’s browser to send a forged HTTP
request, including the victim’s session cookie and any other automatically included
authentication information, to a vulnerable web application. This allows the attacker
to force the victim’s browser to generate requests the vulnerable application thinks
are legitimate requests from the victim."
Most CSRF defences can be bypassed using attacker-controlled script, so the a
required step to protect against A8 is to implement a proper Cross Site Scripting
protection. See the description for A3 above.
OWASP 2007 - A6 – Information Leakage and Improper
Error Handling
Rule of a previous version of the OWASP Top 10 with no equivalent in recent versions. Kept here for reference.
"Applications can unintentionally leak information about their configuration,
internal workings, or violate privacy through a variety of application problems.
Applications can also leak internal state via how long they take to process certain
operations or via different responses to differing inputs, such as displaying the
same error text with different error numbers. Web applications will often leak information
about their internal state through detailed or debug error messages. Often, this
information can be leveraged to launch or even automate more powerful attacks."
CAST supports the protection against "A6 – Information Leakage and Improper Error
Handling" thru the use of the following rules integrated in the technical criteria
metric called "Programming Practices - Error and Exception Handling":
- .NET: Avoid catching an exception of type Exception
- .NET: Avoid empty catch blocks
- .NET: Avoid empty finally blocks
- .NET: Avoid throwing an exception of type Exception
- ABAP: Avoid missing WHEN OTHERS in CASE statements
- ABAP: Avoid unchecked return code (SY-SUBRC) after OPEN SQL or READ statement
- ABAP: Avoid using AT events in combination of LOOP AT .... WHERE constructs
- ASP: Use of error handling page
- COBOL: Avoid DISPLAY ... UPON CONSOLE
- COBOL: Avoid using HANDLE ABEND
- COBOL: Avoid using HANDLE CONDITION
- COBOL: Avoid using IGNORE CONDITION
- COBOL: Include a WHEN OTHER clause when using EVALUATE
- COBOL: Programs accessing relational databases must include the SQLCA copybook
- Java: Avoid catch blocks with assertion
- Java: Avoid catching an exception of type Exception, RuntimeException, or Throwable
- Java: Avoid declaring throwing an exception and not throwing it
- Java: Avoid direct Class inheritance from java.lang.Throwable
- Java: Avoid empty catch blocks
- Java: Avoid empty finally blocks
- Java: Avoid missing default in switch statements
- Java: Avoid return statements in finally blocks
- Java: Avoid throwing an exception in a catch block without chaining it
- Java: Avoid throwing an exception of type Exception
- Java: Avoid using 'java.lang.Error'
- Java: Avoid using 'java.System.exit()'
- Java: Avoid using 'System.err' and 'System.out' outside a try catch block
- Java: Avoid using 'System.err' and 'System.out' within a try catch block
- Java: Avoid using 'System.printStackTrace()' outside a try catch block
- Java: Avoid using 'System.printStackTrace()' within a try catch block
- JSP: Pages should use error handling page
- PL-SQL: Use WHEN OTHERS in exception management
- T-SQL: Avoid Functions and Procedures doing an Insert, Update or Delete without including error management
- T-SQL: Avoid Stored Procedures not returning a status value
- VB: Avoid using "On error Resume Next" in the Class event terminate.
- VB: Use a single Error Handling Method
Security coverage in CAST AIP
Please refer to Security coverage in CAST AIP.