Attackers frequently install backdoors in the form of a PHP Shell, which attackers use to execute commands to the underlying operating system with at least the permissions of the web server. This means that attackers can modify or read any file that the web server is capable of reading. In worst cases, the attacker can install malware and take over the server machine. Presence of such a program could either indicate a successful compromise of the application or an insider threat.

The Django application exposes the serve view of the static files application which is not designed to be deployed in a production environment. According to Django documentation:

"The static files tools are mostly designed to help with getting static files successfully deployed into production. This usually means a separate, dedicated static file server, which is a lot of overhead to mess with when developing locally. Thus, the staticfiles app ships with a quick and dirty helper view that you can use to serve files locally in development.

This view will only work if DEBUG is True.

That's because this view is grossly inefficient and probably insecure. This is only intended for local development, and should never be used in production."

OpenSSL is a popular third-party library used to encrypt network traffic. Depending on the version used, it might contain high profile vulnerabilities such as Heartbleed, ChangeCipherSpec injection, and incorrectly implemented Anonymous Elliptic Curve Diffie-Hellman (AECDH) ciphersuite. An application environment deployed with a vulnerable version of OpenSSL might be subjected to critical security threats including, but not limited to, denial of service, sensitive information disclosure, and unauthorized access to past encrypted information.

Path Normalization Conflict can occur in systems with multi-layered architecture where the components have different approaches to Path Normalization process. An attacker can bypass allow list and deny list ACL rules on intermediate components and as a result sensitive resources are unexpectedly exposed.
Example 1:
Using the proxy_pass directive, NGINX can forward all requests for /publicfolder to the Tomcat server. The developer expects that only this folder is accessible to users. However, an attacker can send the next request http://targetserver/publicfolder/..;/manager/html
NGINX considers ..; to be a folder name so the path matches the rule and this request is forwarded to the Tomcat server.
The Tomcat server considers ..; to indicate parent directory and will map the request to /publicfolder/../manager/html, giving the attacker access to the manager app of Tomcat server.

Application resources containing sensitive information or providing privileged functionality are generally at a greater risk of exploitation. During the reconnaissance phase, an attacker will make attempts to discover such files and directories. Using predictable naming schemes for such resources makes it easier for the attacker to locate them. All the application resources that deal with sensitive functionality such as authentication, administrative tasks, or handling of private information must be sufficiently protected from discovery.

Example 1: In the following example, the admin application is deployed in a predictable URL:

from django.conf.urls import patterns
from django.contrib import admin

admin.autodiscover()

urlpatterns = patterns('',
    ...
    url(r'^admin/', include(admin.site.urls)),
    ...

Resources responsible for storing data must be separated from those that implement application functionality. Programmers must exercise caution when creating temporary or backup resources.

Sample applications are often included with default installation of servers, application frameworks, and integrated development environments. These sample applications are created only for demonstration purposes and are not meant to be deployed on production servers alongside critical applications.

Vulnerabilities in sample applications can lead to the bypass of all the security controls implemented in the custom application code. The lack of conformance with access control restrictions can also expose sensitive system resources.

Sample applications can potentially suffer from several risks:
- Lack of proper file restrictions that allow attackers to read arbitrary files
- Exposing direct connections to backend database servers
- Disclosing valid session identifiers allowing attackers to hijack user sessions
- Remote deletion of arbitrary files
- Arbitrary file uploads
- Disclosure of access control lists and user accounts
- Manipulation of Java processes
- Disclosure of absolute paths to installation directories, web roots
- Disclosure of system environment variables

Sample applications are also more susceptible to vulnerabilities such as Cross-Site Scripting.

Mapping of the application attack surface and discovering hidden or restricted resources is a primary goal of an attacker and is often achieved through automated crawling methods. Similarly, search engines discover information about your site by employing software known as "spiders" to crawl the web. After the spiders find a site, they follow links within the site to gather information about all the pages. The spiders periodically revisit sites to find new or changed content.

Sitemap programs provide a detailed view of a website and its organization. Attackers and search bots can use these programs in addition to crawling and indexing a site. Including sensitive and otherwise restricted resources in the sitemap output could expose sensitive functionality to compromise and aid in the attacker discovery process.

Third-party applications, application servers, and web frameworks with known vulnerabilities expand the attack surface available to the attacker.

Most web applications use a session identifier to uniquely identify users, which is typically stored in a cookie and transmitted transparently between the server and the web browser.


Applications that do not store session identifiers in cookies sometimes transmit them as an HTTP request parameter or as part of the URL. Accepting session identifiers specified in URLs makes it easy for attackers to perform Session Fixation attacks.

Placing session identifiers in URLs can also increase the chances of successful Session Hijacking attacks against the application. Session Hijacking occurs when an attacker takes control of a victim's active session or session identifier. It is common practice for web servers, application servers, and web proxies to store requested URLs. If session identifiers are included in URLs, they are also logged. Increasing the number of places session identifiers are viewed and stored increases the chances they will be compromised by an attacker.

If you are using Tomcat to perform authentication, the Tomcat deployment descriptor file specifies a "Realm" used for authentication. It looks like the following:

Example 1:

  <Realm className="org.apache.catalina.realm.JAASRealm"
         appName="SRN"
         userClassNames="com.srn.security.UserPrincipal"
         roleClassNames="com.srn.security.RolePrincipal"/>

This Realm tag takes an optional attribute called debug, which indicates the log level. The higher the number, the more verbose the log messages. If the debug level is set too high, Tomcat will write all usernames and passwords in plain text to the log file. The cutoff for debugging messages related to Tomcat's JAASRealm is 3 (3 or greater is bad, 2 or less is okay), but this cutoff may vary for the other types of realms that Tomcat provides.

Directly accessing Java Server Pages (JSPs) in applications built using web frameworks, such as Struts or Spring, that use actions or servlets to delegate requests to JSPs can result in unhandled exceptions and system information leaks. Poorly implemented or configured application servers have been co-opted into leaking source code details using specially crafted requests, such as http://host/page.jsp%00 or http://host/page.js%2570. Even worse, if an application permits users to upload arbitrary files, attackers may use this mechanism to upload malicious code in the form of a JSP and request the uploaded page to cause the malicious code to execute on the server.

Example 1: The following example shows a poorly constructed security constraint that explicitly allows direct access to JSPs with a '*' in the role name, which indicates that all users are allowed access the corresponding web resources.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>JSP Access for Everyone!</web-resource-name>
        <description>Allow any user/role access to JSP</description>
        <url-pattern>*.jsp</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>*</role-name>
    </auth-constraint>
</security-constraint>

Duplicate security roles serve no purpose since only the last definition of a given security role will be applied.
Example 1: The entry from a web.xml file defines two admin roles.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>AdminPage</web-resource-name>
        <description>Admin only pages</description>
        <url-pattern>/auth/noaccess/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Administrators only</description>
        <role-name>admin</role-name>
    </auth-constraint>
</security-constraint>
...
<security-role>
    <description>Administrator</description>
    <role-name>admin</role-name>
</security-role>

<security-role>
    <description>Non-Administrator</description>
    <role-name>admin</role-name>
</security-role>

Duplicate servlet mappings serve no purpose since only the last entry will be applied when the same URL pattern is used in multiple servlet mappings.

Example 1: In the following example, the URL pattern /servletA/* is used in two different servlet mappings.

<servlet-mapping>
    <servlet-name>ServletA</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>ServletB</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>

Multiple URL patterns that map to a single Servlet could be a sign that the Servlet performs too many functions.

Example 1: The following example maps five URL patterns to a single Servlet.

<servlet>
    <servlet-class>com.class.MyServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/myservlet</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/helloworld*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/servlet*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/mservlet*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/*</url-pattern>
</servlet-mapping>

The longer a session stays open, the larger the window of opportunity an attacker has to compromise user accounts. While a session remains active, an attacker may be able to brute-force a user's password, crack a user's wireless encryption key, or commandeer a session from an open browser. Longer session timeouts can also prevent memory from being released and eventually result in a denial of service if a sufficiently large number of sessions are created.

Example 1: If the session timeout is zero or less than zero, the session never expires. The following example shows a session timeout set to -1, which will cause the session to remain active indefinitely.

<session-config>
    <session-timeout>-1</session-timeout>
</session-config>

The <session-timeout> tag defines the default session timeout interval for all sessions in the web application. If the <session-timeout> tag is missing, it is left to the container to set the default timeout.

When an attacker explores a web site looking for vulnerabilities, the amount of information that the site provides is crucial to the eventual success or failure of any attempted attacks. If the application shows the attacker a stack trace, it relinquishes information that makes the attacker's job significantly easier. For example, a stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components.

The application configuration should specify a default error page in order to guarantee that the application will never leak error messages to an attacker. Handling standard HTTP error codes is useful and user-friendly in addition to being a good security practice, and a good configuration will also define a last-chance error handler that catches any exception that could possibly be thrown by the application.

The WebLogic deployment descriptor should specify a session identifier length of at least 24 bytes. A shorter session identifier leaves the application open to brute-force session guessing attacks. If an attacker can guess an authenticated user's session identifier, he can take over the user's session. The remainder of this explanation will detail a back-of-the-envelope justification for a 24-byte session identifier.

The session identifier is composed of a pseudorandom selection of the 62 alphanumeric characters, which means that if the string were composed in a truly random fashion each byte could yield a maximum of 6 bits of entropy.

The expected number of seconds required to guess a valid session identifier is given by the equation:

(2^B+1) / (2*A*S)

Where:

- B is the number of bits of entropy in the session identifier.

- A is the number of guesses an attacker may try each second.

- S is the number of valid session identifiers that are valid and available to be guessed at any given time.

The number of bits of entropy in the session identifier is always less than the total number of bits in the session identifier. For example, if session identifiers were provided in ascending order, there would be close to zero bits of entropy in the session identifier no matter the identifier's length. Assuming that the session identifiers are being generated using a good source of random numbers, we will estimate the number of bits of entropy in a session identifier to be half the total number of bits in the session identifier. For realistic identifier lengths this is possible, though perhaps optimistic.

If attackers use a botnet with hundreds or thousands of drone computers, it is reasonable to assume that they could attempt tens of thousands of guesses per second. If the web site in question is large and popular, a high volume of guessing might go unnoticed for some time.

A lower bound on the number of valid session identifiers that are available to be guessed is the number of users that are active on a site at any given moment. However, any users that abandon their sessions without logging out will increase this number. (This is one of many good reasons to have a short inactive session timeout.)

With a 64-bit session identifier, assume 32 bits of entropy. For a large web site, assume that the attacker may try 1,000 guesses per second and that there are 10,000 valid session identifiers at any given moment. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is less than 4 minutes.

Now assume a 128-bit session identifier that provides 64 bits of entropy. With a very large web site, an attacker might try 10,000 guesses per second with 100,000 valid session identifiers available to be guessed. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is greater than 292 years.

Working backwards from bits to bytes, now, the session identifier must be 128/6, which yields approximately 21 bytes. Furthermore, empirical testing has demonstrated that the first three bytes of the session identifier do not appear to be randomly generated, which means to achieve our desired 64 bits of entropy we need to configure WebLogic to use a session identifier 24 bytes in length.

A missing or duplicate servlet name in web.xml is an error. Every Servlet should have a unique name (servlet-name) and a corresponding mapping (servlet-mapping).

Example 1: The following entry from web.xml shows several erroneous servlet definitions.

<!-- No <servlet-name> specified: -->
    <servlet>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

<!-- Empty <servlet-name> node: -->
    <servlet>
        <servlet-name/>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

<!-- Duplicate <servlet-name> nodes: -->
    <servlet>
        <servlet-name>MyServlet</servlet-name>
        <servlet-name>Servlet</servlet-name>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

These errors may cause an unintentional denial of access to the Servlet.

The <login-config> element is used to configure how users authenticate to an application. A missing authentication method means the application does not know how to apply authorization constraints since no one can log in. The authentication method is specified using the <auth-method> tag, which is a child of <login-config>.

There are four authentication methods: BASIC, FORM, DIGEST, and CLIENT_CERT.

BASIC denotes HTTP Basic authentication.
FORM denotes Form-based authentication.
DIGEST is like BASIC authentication; however, in DIGEST the password is encrypted.
CLIENT_CERT requires that clients have Public Key Certificates and use SSL/TLS.

Example 1: The following configuration does not specify a login configuration.

<web-app>

    <!-- servlet declarations -->
    <servlet>...</servlet>

    <!-- servlet mappings-->
    <servlet-mapping>...</servlet-mapping>

    <!-- security-constraints-->
    <security-constraint>...</security-constraint>

    <!-- login-config goes here -->

    <!-- security-roles -->
    <security-role>...</security-role>

</web-app>

web.xml security constraints are typically used for role based access control, but the optional user-data-constraint element specifies a transport guarantee that prevents content from being transmitted insecurely.

Within the <user-data-constraint> tag, the <transport-guarantee> tag defines how communication should be handled. There are three levels of transport guarantee:

1) NONE means that the application does not require any transport guarantees.
2) INTEGRAL means that the application requires that data sent between the client and server be sent in such a way that it cannot be changed in transit.
3) CONFIDENTIAL means that the application requires that data be transmitted in a fashion that prevents other entities from observing the contents of the transmission.



In most circumstances, the use of INTEGRAL or CONFIDENTIAL means that SSL/TLS is required. If the <user-data-constraint> and <transport-guarantee> tags are omitted, the transport guarantee defaults to NONE.

Example 1: The following security constraint does not specify a transport guarantee.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Storefront</web-resource-name>
        <description>Allow Customers and Employees access to online store front</description>
        <url-pattern>/store/shop/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Anyone</description>
        <role-name>anyone</role-name>
    </auth-constraint>
</security-constraint>