Review your Application Architecture Today !


Application architecture review can be defined as reviewing the current security controls in the application architecture. This helps a user to identify potential security flaws at an early stage and mitigate them before starting the development stage. Poor design of architecture may expose the application to many security loopholes. It is preferable to perform the architecture review at the design stage, as the cost and effort required for implementing security after development is high.

This document can be considered as the secure design guideline for the architects or as a checklist for penetration tester to perform application architecture review as a part of the overall security assessment.

The following diagram shows some of the primary issues that must be addressed at the designing stage.

While doing the architecture review we can primarily focus on the following areas:

  1. Application Architecture Documents
  2. Deployment and Infrastructure Considerations
  3. Input Validation
  4. Authentication
  5. Authorization
  6. Configuration Management
  7. Session Management
  8. Cryptography
  9. Parameter Manipulation
  10. Exception Management
  11. Auditing & Logging
  12. Application Framework and Libraries

Additional category or points under any category can be added as per the requirement. Let’s have a look at each area separately:

Application Architecture Documents:

The first thing to look for is the availability of the application architecture document. Every application should have a properly documented architecture diagram with a high-level explanation of the above points and a network connectivity diagram showing how different component are placed and secured.

Deployment and Infrastructure Considerations:

Review the infrastructure on which the application is deployed. This can include reviewing the network, system, infrastructure performance monitoring, etc.

Some of the points which should be taken into consideration are as follows:

  • Components required for the application: What is the OS supporting the application, hardware requirement, etc.?
  • Restrictions applied on the firewall: Review the firewall policies defined for the application. What type of traffic is allowed and what type of traffic is blocked?
  • Port and Service requirement: An application may communicate with other application as well. Identify which ports and services are required to be open for the application.
  • Component Segregation: Components of the application should be segregated from each other. For example, the application server and database server should not reside in the same machine.
  • Disable clear text protocol: Ports running clear text services like (HTTP, FTP, etc.) should be closed and not used for any part of the application.

Input Validation

Weak input validation is one of the main reasons for application security weakness. Proper input validation can help in preventing many attacks like Cross-Site Scripting, SQL Injection, etc. The validation should be applied on every input field (including the hidden form field) of all the pages. The best practice is to use a centralized approach.

Some of the points which should be taken into consideration are as follows:

  • Mechanism to validate the user inputs: Check if the application is validating the user input or processing the input as it is.
  • Bypassing the validation: Check how the user input is being validated. Is it possible to bypass the validation, for example, encoding the input? Identify if input validation depends on the application framework. Check whether there is any vulnerability in the framework through which a user can bypass the validation.
  • Centralized approach: If custom implementation to validate the user input is present, check whether the approach is centralized.
  • Validating across all the tiers: As a best practice, validation should be applied on all the layers, i.e. business layer, data layer, etc.
  • Addressing SQL Injection issue: Input validation helps in mitigating SQL Injection issue to some extent. Check whether the application is safe against the SQL Injection vulnerability by using parameterized query in the back end.


Authentication is the act of verifying a user’s identity. In the application, it is achieved by providing the username and password. Weak authentication mechanism can result in bypassing the login process and accessing the application. This can lead to a major compromise. The application should be designed with strong authentication.

Some of the points which should be taken into consideration are as follows:

  • Authentication control on the server side: Make sure the credentials are verified at the server side and not on the client side. Client-side validation can be easily bypassed.
  • Secure channel for authentication: Login credentials should always be sent through an encrypted channel. Credentials going through a clear text channel can be easily sniffed by the attacker.
  • Check whether the login page is served over HTTP protocol. Check whether the application can be accessible on any other port where SSL certificate is not implemented.
  • Change password page: Check whether the Old Password field is present in the Change Password page and verified as well.
  • Strong password policy: An application should be configured to accept strong passwords only. Weak passwords can be brute forced easily.
  • Authentication cookie: Check if SSL is implemented on an entire application and the authentication cookie is not sent in clear text on any page.
  • Service account: Service account is an account under which a service application is running. A service account is required for the application and communicating with the database should have a restrictive set of privilege.
  • Default framework password: Many application framework comes with a default password. Make sure the password is changed to a non-guessable strong password.


Authorization determines which resources can be accessed by the authenticated user. Weak authorization control can lead to Privileges Escalation attacks.

Some of the points which should be taken into consideration are as follows:

  • Privilege escalation and spoofing: Privilege escalation happens when a user gets access to more resources than they are allowed or when the user can perform additional actions than they are allowed. Check the controls present when the user tries to escalate his/her privilege through manipulating the request or by directly accessing the unauthorized page/resource.
  • Direct object reference: Check whether the application provides direct access to the objects based on the user-supplied input. This may allow the attacker to access the resources belonging to other users by bypassing the authorization. For example, downloading the invoices/statement of other users.

Configuration Management

Weak configuration should be avoided. Any sensitive information being stored in the configuration file can be extracted by the attacker.

Some of the points which should be taken into consideration are as follows:

  • Secure Hardening: Make sure all the components required for the application are updated and the latest patches are applied on them. The default configuration should be changed wherever possible.
  • Sensitive Data: Sensitive data like database connection string, encryption key, admin credentials or any other secret should not be stored as clear text in the code. Check whether the configuration file is secured against the unauthorized access.
  • Persistent cookie: Storing sensitive data as plaintext in a persistent cookie should be avoided. The user can see and modify the clear text data. Check if the application is storing the clear text data in a persistent cookie.
  • Passing sensitive data using GET protocol: The GET protocol sends the data in the query string. Sensitive information going in a GET request can be accessed from the browser history or logs.
  • Disable unused methods: Verify that the application accepts only GET and POST methods. Other methods like TRACE, PUT, DELETE, etc. should be disabled.
  • Sensitive data over HTTP: Communication between the components, such as between application server and database server, should be encrypted.

Session Management

The session is the track of the user activities. Strong session management plays an important role in the overall security of the application. Weakness in the session management may lead to serious attacks.

Some of the points which should be taken into consideration are as follows:

  • Use framework’s default session management: Custom session management can have multiple vulnerabilities. Ensure there is no custom manager is being used and the application framework’s default session management is used.
  • Ensure session management best practices are followed:
    • The session ID is random, long and unique.
    • The session is invalidating after logout.
    • The session ID is changing on successful authentication and re-authentication.
    • The session ID is not going in URL.
    • The session is timed out after a certain period of inactivity.
    • The session ID is going insecure channel like SSL.
    • Check whether cookie attributes (HttpOnly, Secure, path and domain) are secured.


Applications frequently use cryptography to secure the stored data or to protect the data in transit over an insecure channel.

Some of the points which should be taken into consideration are as follows:

  • Custom Implementation: Designing a dedicated encryption mechanism may lead to weaker protection. Secure cryptographic service provided by the platform should be used. Check what type of encryption is being used in the application.
  • Encryption Key management: Check whether there is any policy on encryption key management, i.e., Key generation, distribution, deletion, and expiration.
  • Securing encryption keys: Encryption keys are used as an input to encrypt or decrypt the data. If encryption keys are compromised, the encrypted data can be decrypted and hence, will be no longer be secure.
  • Key recycle policy: The key should be recycled after a certain period. Using the same key for a long time is not a safe practice.

Parameter Manipulation

With Parameter Manipulation attacks, the attacker modifies the data going from application to the web server. This can result in unauthorized access to services.

Some of the points which should be taken into consideration are as follows:

  • Validate all inputs from the client: Validation applied on the client side may reduce the load on the server but relying only on client-side validation is not a safe practice. Client-side validation can be bypassed using a proxy tool. Check whether validation is applied on the server as well.
  • Do not rely on HTTP header: Security decision in the application should not be based on the HTTP header. If the application is serving any page by checking only the “referrer” header, then an attacker can bypass this by changing the header in a proxy tool.
  • Encrypt the cookie: Cookies can have data that is being used on the server to authorize the user. This type of data should be protected against unauthorized manipulation attacks.
  • Sensitive data in view state: View state in an ASP.NET application can have sensitive data that is required to take the authorization decision on the server. Data in view state can be tempered if MAC (message authentication code) is not enabled. Check whether view state is protected using MAC.

Exception Management

Insecure exception handling can expose the valuable information, which can be used by the attacker to fine-tune his attack. Without exception management, information such as stack trace, framework details, server details, SQL query, internal path and other sensitive information can be exposed. Check whether centralized exception management is in place, with minimum information being displayed.

Auditing & Logging

Log files contain the record of the events. These events can be a success or failed login attempt, data retrieval, modification, deletion, network communication, etc. The logs should be monitored in real time.

Some of the points which should be taken into consideration are as follows:

  • Logging enabled: Check if logging is enabled for application and platform level as well.
  • Log events: Logs should be generated for all security-level important events like successful and failed authentication, data access, modification, network access, etc. The log should include time of the event, user identity, location with machine name, etc. Identify which events are being logged.
  • Logging sensitive data: An application should not log sensitive data like user credentials, password hashes, credit card details, etc.
  • Storage, security, and analysis:
    • The log file should be stored on a different partition than the one on which the application is running. The log file should be copied and moved to permanent storage for retention.
    • The log files must be protected against the unauthorized access, modification or deletion.
    • The log file should be analyzed on a regular interval.

Application Framework and Libraries

Make sure that the application framework and libraries are up to date and relevant patches are applied on them. Verify that there is no default password being used in the framework (admin/admin, tomcat/tomcat, etc.). Check whether the old or vulnerable framework is in use.


The above points represent the key areas for secure designing of the application. Implementing these points at the designing stage can reduce the overall cost and effort to secure the application. If the application is already deployed, secure architecture review is an important part of the overall security assessment and can help in fixing the existing vulnerabilities and improving the future design.

Hits: 1626

HTTP/2 DoS CVEs Affect Kubernetes too !

Two high severity vulnerabilities impacting all versions of the Kubernetes open-source system for handling containerised apps can allow an unauthorised attacker to trigger a denial-of-service (DoS) state.

Kubernetes development team has already released patched versions to address these newly found security flaws and block potential attackers from exploiting them.

Kubernetes was originally developed by Google using Go and it is designed to help automate the deployment, scaling, and management of containerised workloads and services over clusters of hosts.

It does this by organising app containers into pods, nodes (physical or virtual machines), and clusters, with multiple nodes forming a cluster that is managed by a master which coordinates cluster-related tasks such as scaling, scheduling, or updating apps.

Security flaws impact all Kubernetes versions

“A security issue has been found in the net/http library of the Go language that affects all versions and all components of Kubernetes,” disclosed Kubernetes Product Security Committee’s Micah Hausler on the announcement list for Kubernetes security issues.

“The vulnerabilities can result in a DoS against any process with an HTTP or HTTPS listener,” with all versions of Kubernetes being affected.

Netflix announced the discovery of multiple vulnerabilities exposing servers that come with support for HTTP/2 communication to DoS attacks on August 13.

Out of the eight CVEs issued by Netflix with their security advisory, two of them also impact Go and all Kubernetes components designed to serve HTTP/2 traffic (including /healthz).

The two weaknesses tracked as CVE-2019-9512 and CVE-2019-9514 have been assigned CVSS v3.0 base scores of 7.5 by the Kubernetes Product Security Committee, and they make it possible for “untrusted clients to allocate an unlimited amount of memory, until the server crashes.”

  1. CVE-2019-9512 Ping Flood: attacker sends continual pings to an HTTP/2 peer, causing the peer to build an internal queue of responses. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service.
  2. CVE-2019-9514 Reset Flood: attacker opens a number of streams and sends an invalid request over each stream that should solicit a stream of RST_STREAM frames from the peer. Depending on how the peer queues the RST_STREAM frames, this can consume excess memory, CPU, or both, potentially leading to a denial of service.

Upgrade your Kubernetes clusters

As mentioned in the beginning, Kubernetes has already released patches to address the vulnerabilities and all admins are advised to upgrade to a patched version as soon as possible.

The following Kubernetes releases built using new and patched versions of Go have been issued by the development team to help admins mitigate the vulnerabilities:

• Kubernetes v1.15.3 - go1.12.9
• Kubernetes v1.14.6 - go1.12.9
• Kubernetes v1.13.10 - go1.11.13

Hits: 156

HTTP/2 Vulnerable to 8 DoS Attacks | CVE IDs declared


Netflix has discovered several resource exhaustion vectors affecting a variety of third-party HTTP/2 implementations. These attack vectors can be used to launch DoS attacks against servers that support HTTP/2 communication.

Netflix worked with Google and CERT/CC to coordinate disclosure to the Internet community.

Today, a number of vendors have announced patches to correct this suboptimal behaviour. While we haven’t detected these vulnerabilities in our open source packages, we are issuing this security advisory to document our findings and to further assist the Internet security community in remediating these issues.


There are three broad areas of information security: confidentiality (information can’t be read by unauthorised people), integrity (information can’t be changed by unauthorised people), and availability (information and systems are available when you want them). All of the changes announced today are in the “availability” category. These HTTP/2 vulnerabilities do not allow an attacker to leak or modify information.

Rather, they allow a small number of low bandwidth malicious sessions to prevent connection participants from doing additional work. These attacks are likely to exhaust resources such that other connections or processes on the same machine may also be impacted or crash.

The Weaknesses:

HTTP/2 (defined in RFCs 7540 and 7541) represents a significant change from HTTP/1.1. There are several new capabilities, including header compression and multiplexing of data from multiple streams, which make this attractive to the user community. To support these new features, HTTP/2 has grown to encompass some of the complexity of a Layer 3 transport protocol:

  • Data is now carried in binary frames;
  • There are both per-connection and per-stream windows that define how much data can be sent;
  • There are several ICMP-like control messages (ping, reset, and settings frames, for example) which operate at the HTTP/2 connection layer; and,
  • This is a fairly robust concept of stream prioritization.

While this added complexity enables some exciting new features, it also raises implementation questions. When implementations run on the internet and are exposed to malicious users, implementers may wonder:

  • Should I limit any of the control messages?
  • How do I implement the priority queueing scheme in a computationally efficient way?
  • How do I implement the flow-control algorithms in a computationally efficient way?
  • How could an attacker manipulate the flow-control algorithm at the HTTP/2 layer to cause unintended results? (And, can they manipulate the flow-control algorithms at both the HTTP/2 and TCP layers together to cause unintended results?)

The Security Considerations section of RFC 7540 (see Section 10.5) addresses some of this in a general way. However, unlike the expected “normal” behavior—which is well-documented and which implementations seem to follow very closely—the algorithms and mechanisms for detecting and mitigating “abnormal” behavior are significantly more vague and left as an exercise for the implementer. From a review of various software packages, it appears that this has led to a variety of implementations with a variety of good ideas, but also some weaknesses.

Why does this matter?

Most of these attacks work at the HTTP/2 transport layer. As illustrated in the diagram below, this layer sits above the TLS transport, but below the concept of a request. In fact, many of these attacks involve either 0 or 1 requests.

http2 diagram

Since the early days of HTTP, tooling has been oriented around requests: logs often indicate requests (rather than connections); rate-limiting may occur at the request level; and, traffic controls may be triggered by requests.

By contrast, there is not as much tooling that looks at HTTP/2 connections to log, rate-limit, and trigger remediation based on a client’s behavior at the HTTP/2 connection layer. Therefore, organizations may find it more difficult to discover and block malicious HTTP/2 connections and may need to add additional tooling to handle these situations.

These attack vectors allow a remote attacker to consume excessive system resources. Some are efficient enough that a single end-system could potentially cause havoc on multiple servers. Other attacks are less efficient; however, even less efficient attacks can open the door for DDoS attacks which are difficult to detect and block.


Many of the attack vectors we found (and which were fixed today) are variants on a theme: a malicious client asks the server to do something which generates a response, but the client refuses to read the response. This exercises the server’s queue management code. Depending on how the server handles its queues, the client can force it to consume excess memory and CPU while processing its requests.

These are the attacks which are being disclosed today, all discovered by Jonathan Looney of Netflix, except for CVE-2019-9518 which was discovered by Piotr Sikora of Google:

  • CVE-2019-9511 “Data Dribble”: The attacker requests a large amount of data from a specified resource over multiple streams. They manipulate window size and stream priority to force the server to queue the data in 1-byte chunks. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service.
  • CVE-2019-9512 “Ping Flood”: The attacker sends continual pings to an HTTP/2 peer, causing the peer to build an internal queue of responses. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service.
  • CVE-2019-9513 “Resource Loop”: The attacker creates multiple request streams and continually shuffles the priority of the streams in a way that causes substantial churn to the priority tree. This can consume excess CPU, potentially leading to a denial of service.
  • CVE-2019-9514 “Reset Flood”: The attacker opens a number of streams and sends an invalid request over each stream that should solicit a stream of RST_STREAM frames from the peer. Depending on how the peer queues the RST_STREAM frames, this can consume excess memory, CPU, or both, potentially leading to a denial of service.
  • CVE-2019-9515 “Settings Flood”: The attacker sends a stream of SETTINGS frames to the peer. Since the RFC requires that the peer reply with one acknowledgement per SETTINGS frame, an empty SETTINGS frame is almost equivalent in behavior to a ping. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service.
  • CVE-2019-9516 “0-Length Headers Leak”: The attacker sends a stream of headers with a 0-length header name and 0-length header value, optionally Huffman encoded into 1-byte or greater headers. Some implementations allocate memory for these headers and keep the allocation alive until the session dies. This can consume excess memory, potentially leading to a denial of service.
  • CVE-2019-9517 “Internal Data Buffering”: The attacker opens the HTTP/2 window so the peer can send without constraint; however, they leave the TCP window closed so the peer cannot actually write (many of) the bytes on the wire. The attacker then sends a stream of requests for a large response object. Depending on how the servers queue the responses, this can consume excess memory, CPU, or both, potentially leading to a denial of service.
  • CVE-2019-9518 “Empty Frames Flood”: The attacker sends a stream of frames with an empty payload and without the end-of-stream flag. These frames can be DATA, HEADERS, CONTINUATION and/or PUSH_PROMISE. The peer spends time processing each frame disproportionate to attack bandwidth. This can consume excess CPU, potentially leading to a denial of service. (Discovered by Piotr Sikora of Google)

Workarounds and Fixes

In most cases, an immediate workaround is to disable HTTP/2 support. However, this may cause performance degradation, and it might not be possible in all cases. To obtain software fixes, please contact your software vendor. More information can also be found in the CERT/CC vulnerability note.

Hits: 508