How Cyberwall covers the OWASP Top-10 Vulnerabilities in Web Applications (and more)
With Cyberwall, websites are much harder to attack, because users can only interact with an HTML5-Stream
Limited user inputs: Cyberwall accepts only a) mouse events and b) key strokes into form fields in the client application (with input frequency capping and special encodings/mark-ups filtered out). All other user interactions are filtered.
Limited HTTP requests: Cyberwall doesn‘t forward any forged HTTP requests to the source application. All resources are streamed from the built-in browser engine, only valid resources and application data can be forwarded to and from the client.
Invisible backend servers: No information about resources behind Cyberwall is visible (incl. application servers, database servers and third party resources). All resources are hidden behind the Cyberwall, attackers simply can‘t interact with them.
Isolated backend servers: Any potential hacking attempt for a given web application first needs to control the Cyberwall server, and could only then attempt to exploit vulnerable application servers and systems. Firewalls can be used to limit incoming connection requests from Cyberwall containers only.
XSS or other cross-site attacks become very hard to facilitate, since information can‘t be easily injected into or extracted from the secure isolated Cyberwall containers. The entire website, including all potentially injected Scripts, is executed at the Cyberwall server. No content scripts are passed on to the client browser.
Limited connectivity from the browsing container: In difference to normal, untrusted web clients, Cyberwall executes all code of the web application inside a trusted, isolated environment. Malicious client-side code injected by third parties or by network level attackers can‘t extract information due to whitelisting. Application credentials or session cookies can‘t be transmitted to third parties (unknown domains). This way unwanted data-leakage or client-side session hijacking is stopped.
Cyberwall’s protection at the example of the Open Web Application Security Project’s Top-10 vulnerabilities
A-1 Injections: Injection flaws, such as SQL, OS, and LDAP injections occur when untrusted data is sent to an interpreter (such as a server). The attacker’s hostile data can trick the website into executing unintended commands or to provide sensitive data which it shouldn’t.
1: Cyberwall prevents any kind of user input forging or request manipulation (e.g. URL manipulation, parameter injection). Only the trusted browsing container can interact with the application. User interaction is limited to mouse and text input. 2: Potential injections into normal input fields are prevented using filtering (encodings, special mark-ups) and rate limiting (characters per minute). Injections using basic input fields are very rare in real applications.
A-2 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.
Nowadays, most security problems in web authentication arise from complex, asynchronous, client-side API calls or from federated login pages. Cyberwall prevents these problems by hiding all client-side requests, authentication servers and other backend systems from attackers. With Cyberwall, only the basic credentials need to be correctly validated by the application, all application internals are shielded from potential attacks. Dictionary attacks are prevented by basic input rate limiting on user name and password fields.
A-3 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.
XSS or other cross-site attacks become very hard to facilitate, since information can‘t be easily injected into or extracted from the trusted, isolated Cyberwall containers. Cyberwall allows external connections only if they are whitelisted and prevents network connections to unknown third parties. Most forms of XSS are blocked by significantly complicating injections into the active session and by preventing credential extraction or real-time session hijacking, because of network restrictions imposed on Cyberwall’s browsing sessions.
A-4 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.
Direct object references are not possible with Cyberwall. The only way to access an (HTTP) resource behind Cyberwall is via the Cyberwall client - mouse inputs and keystrokes. It will only open resources as reaction on click events and if the session access is legitimate, no direct references are possible.
A-5 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.
Potential security misconfiguration can neither be identified nor exploited. 1. The Cyberwall isolation model shields backend servers from attackers, because Cyberwall acts as browser-in-the-middle. Only legitimate user interactions (mouse clicks) can be executed. Therefore, identifying server misconfiguration, finding potentially outdated server versions, gathering information about OS or network stack, doesn’t work. Server Status Pages, Configuration Summaries or even HTTP-headers can’t be retrieved or analysed, neither with automated tools, nor manually. 2. Even if security misconfigurations within the systems behind Cyberwall should be known, they couldn’t be exploited. Because the systems behind Cyberwall can’t be addressed directly.
A-6 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.
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.
A-7 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.
Cyberwall protects from missing function level access control by design. Due to its streaming approach, Cyberwall ensures that applications can be used only in ways the user interface allows. Because no direct interaction with the server is possible, missing server-side access control checks can’t endanger the security of the underlying web application. Request forging is generally impossible. Attackers and users alike can’t misuse or exploit any server-side functions.
A-8 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.
Comparable to A-3 Cross-Site-Scripting, CSRF is very hard to perform through Cyberwall. All scripts are executed at the Cyberwall server and Cyberwall will not send any information to unknown external servers or request unknown URIs. Also, all session cookies remain at the Cyberwall container and are not transferred to the real users’ browsers. Even if a user opens a malicious website, while logged in at the Cyberwall-protected website, attackers will not be able to steal credentials.
A-9 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.
Like for other vulnerabilities, Cyberwall protects due to its architecture. 1. Addressing vulnerable components (libraries, frameworks, etc.) directly is not possible behind Cyberwall. 2. User input to form fields in the client application is protected due to input frequency capping and special encodings/mark-ups filtered out. Also, identifying the components of a website, e.g. a Wordpress CMS, is more much difficult and usually can't be done with common automatic scanning tools, because Cyberwall requires a complete browsing session and real user inputs, HTTP-based attack tools just don't work any longer.
A-10 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 unauthorized pages. Encryption at rest or in transit, as well as special precautions when exchanged with the browser.
Cyberwall executes a full browsing-engine on behalf of an enduser. Inside the engine, valid domains and URLs can be whitelisted for a protected application. Redirects or Forwards to unknown, potentially malicious domains can’t happen, but trigger security incidents being forwarded to system administrators. Because the real browser executes only the Cyberwall client, no redirections can happen at the client as well. The client browser only displays the virtual browser stream using the secured Cyberwall HTML5 client.