The Open Web Application Security Project (OWASP) is a non-profit foundation that works the improve the security of software through open-source projects. One such project is outlining the ten most critical security concerns for application security, known as the OWASP Top Ten. This two-part blog will take a look at each of these, and how enterprises can use API management to prevent these threats.
API management has long helped customers simplify and accelerate the security, integration and management of their web services and web API traffic. Many enterprises are looking to extend that same functionality to web applications (like many of the functions a web application firewall might provide) and are looking to consolidate appliances into a single platform. Depending on your requirements, an API management solution can be your one security gateway for all web services, APIs and application traffic.
Let’s take a look at the first five of the OWASP Top Ten concerns. I’ll describe each of these threats as defined by The OWASP Top Ten Project, and how to protect your enterprise from that threat.
A1 Injection: Injection flaws, such as SQL, NoSQL, 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.
API management solutions often provide policy assertions to protect against SQL and other types of injection attacks. They generally also have full access to all web request and response content and context to enable inspection and protection at runtime.
A2 Broken Authentication: Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.
API management solutions can require strong or multifactor authentication over secure protocols and can protect against brut e force attacks using simple or sophisticated rate limiting or throughput quota policies.
Through policy management, API management platforms usually can also detect and protect against session=based attacks by controlling cookie security attributes, using digital signatures and encryption or tracking and mapping and enforcing sticky session identifiers sent in a variety of ways.
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.
Through policy management, API management solutions may be able to require encryption at rest or in-transit, and often can be configured to be PCI-DSS compliant – meeting the needs of regulated industries such as financial, healthcare, and public sector.
A4 XML External Entities: 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.
API management solutions usually can be configured to protect against remote code execution and denial of services (DoS) attacks.
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.
API management solutions may provide a range of proprietary and industry-standard access control mechanisms to ensure that protected resources can only be accessed by authenticated and authorized users and applications using centralized security policies.
In my next blog, I’ll take a look at Threats 6-10 (similar to the above).