STIGQter: STIG Summary: Application Security and Development Security Technical Implementation Guide Version: 5 Release: 1 Benchmark Date: 23 Oct 2020: STIGQter: STIG Summary: Application Security and Development Security Technical Implementation Guide Version: 5 Release: 1 Benchmark Date: 23 Oct 2020:SV-222605r561266_rule
V-222605
SRG-APP-000251
APSC-DV-002520
CAT II
10
A suitable canonical form should be chosen and all user input canonicalized into that form before any authorization decisions are performed.
Security checks should be carried out after decoding is completed. Moreover, it is recommended to check that the encoding method chosen is a valid canonical encoding for the symbol it represents.
Review the application documentation and interview the application administrator for details regarding security assessment code reviews or vulnerability scans.
Review the scan results from the entire application. This can be provided as results from an automated code review or a vulnerability scanning tool.
Review the scan results to determine if there are any existing canonical representation vulnerabilities.
Review web server and application configuration.
The OWASP website provides the following test procedures:
"Investigate the web application to determine if it asserts an internal code page, locale, or culture.
If the default character set, locale is not asserted it will be one of the following:
HTTP Posts. Interesting tidbit: All HTTP posts are required to be ISO 8859-1, which will lose data for most double byte character sets. You must test your application with your supported browsers to determine if they pass in fully encoded double byte characters safely
HTTP Gets. Depends on the previously rendered page and per-browser implementations, but URL encoding is not properly defined for double byte character sets. IE can be optionally forced to do all submits as UTF-8 which is then properly canonicalized on the server
.NET: Unicode (little endian)
JSP implementations, such as Tomcat: UTF8 - see “javaEncoding” in web.xml by many servlet containers
Java: Unicode (UTF-16, big endian, or depends on the OS during JVM startup)
PHP: Set in php.ini, ISO 8859-1”
If the results are not provided or the application representative cannot demonstrate that the application does not use Unicode encoding, this is a finding.
V-222605
False
APSC-DV-002520
Review the application documentation and interview the application administrator for details regarding security assessment code reviews or vulnerability scans.
Review the scan results from the entire application. This can be provided as results from an automated code review or a vulnerability scanning tool.
Review the scan results to determine if there are any existing canonical representation vulnerabilities.
Review web server and application configuration.
The OWASP website provides the following test procedures:
"Investigate the web application to determine if it asserts an internal code page, locale, or culture.
If the default character set, locale is not asserted it will be one of the following:
HTTP Posts. Interesting tidbit: All HTTP posts are required to be ISO 8859-1, which will lose data for most double byte character sets. You must test your application with your supported browsers to determine if they pass in fully encoded double byte characters safely
HTTP Gets. Depends on the previously rendered page and per-browser implementations, but URL encoding is not properly defined for double byte character sets. IE can be optionally forced to do all submits as UTF-8 which is then properly canonicalized on the server
.NET: Unicode (little endian)
JSP implementations, such as Tomcat: UTF8 - see “javaEncoding” in web.xml by many servlet containers
Java: Unicode (UTF-16, big endian, or depends on the OS during JVM startup)
PHP: Set in php.ini, ISO 8859-1”
If the results are not provided or the application representative cannot demonstrate that the application does not use Unicode encoding, this is a finding.
M
4093