Often Misused: Authentication

ABSTRACT

Attackers can spoof DNS entries. Do not rely on DNS names for security.

EXPLANATION

Many DNS servers are susceptible to spoofing attacks, so you should assume that your software will someday run in an environment with a compromised DNS server. If attackers are allowed to make DNS updates (sometimes called DNS cache poisoning), they can route your network traffic through their machines or make it appear as if their IP addresses are part of your domain. Do not base the security of your system on DNS names.


Example: The following code uses a DNS lookup to determine whether an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status.


String ip = request.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip);
if (addr.getCanonicalHostName().endsWith("trustme.com")) {
trusted = true;
}


IP addresses are more reliable than DNS names, but they can also be spoofed. Attackers can easily forge the source IP address of the packets they send, but response packets will return to the forged IP address. To see the response packets, the attacker has to sniff the traffic between the victim machine and the forged IP address. In order to accomplish the required sniffing, attackers typically attempt to locate themselves on the same subnet as the victim machine. Attackers may be able to circumvent this requirement by using source routing, but source routing is disabled across much of the Internet today. In summary, IP address verification can be a useful part of an authentication scheme, but it should not be the single factor required for authentication.

REFERENCES

[1] Standards Mapping - OWASP Top 10 2013 - (OWASP 2013) A2 Broken Authentication and Session Management

[2] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A3 Broken Authentication and Session Management

[3] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A3 Broken Authentication and Session Management

[4] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A7 Broken Authentication and Session Management

[5] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3460 CAT I

[6] Standards Mapping - Security Technical Implementation Guide Version 3.4 - (STIG 3.4) APP3460 CAT I

[7] Standards Mapping - Security Technical Implementation Guide Version 3.5 - (STIG 3.5) APP3460 CAT I

[8] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 247, CWE ID 292, CWE ID 558, CWE ID 807

[9] Standards Mapping - FIPS200 - (FISMA) IA

[10] Standards Mapping - Web Application Security Consortium 24 + 2 - (WASC 24 + 2) Insufficient Authentication

[11] Standards Mapping - SANS Top 25 2010 - (SANS 2010) Porous Defenses - CWE ID 807

[12] Standards Mapping - SANS Top 25 2011 - (SANS Top 25 2011) Porous Defenses - CWE ID 807

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 - (PCI 3.0) Requirement 6.5.10

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.3

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.5.7

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.8

[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 - (NIST SP 800-53 Rev.4) SC-23 Session Authenticity


Copyright 2014 Fortify Software - All rights reserved.
(Generated from version 2014.1.0.0010 of the Fortify Secure Coding Rulepacks)
desc.semantic.java.often_misused_authentication