Endpoints
http://target:7070:7070/WebGoat with 10 active findings
Finding 282: Cross-Site Request Forgery (891258982) [ csrf form rdiff token ]
Product:
MyApp
Status:
Active, Verified
Severity:
High (S1)
Description / Exploit:
In the majority of today’s web applications, clients are required to submit forms which can perform sensitive operations. An example of such a form being used would be when an administrator wishes to create a new user for the application. In the simplest version of the form, the administrator would fill-in: * Name * Password * Role (level of access) Continuing with this example, Cross Site Request Forgery (CSRF) would occur when the administrator is tricked into clicking on a link, which if logged into the application, would automatically submit the form without any further interaction. Cyber- criminals will look for sites where sensitive functions are performed in this manner and then craft malicious requests that will be used against clients via a social engineering attack. There are 3 things that are required for a CSRF attack to occur: 1\. The form must perform some sort of sensitive action. 2\. The victim (the administrator the example above) must have an active session. 3\. Most importantly, all parameter values must be known or guessable. Arachni discovered that all parameters within the form were known or predictable and therefore the form could be vulnerable to CSRF. Manual verification may be required to check whether the submission will then perform a sensitive action, such as reset a password, modify user profiles, post content on a forum, etc.
Impact:
No impact provided
Systems Vulnerable:
Suggested Mitigation:
Based on the risk (determined by manual verification) of whether the form + submission performs a sensitive action, the addition of anti-CSRF tokens may + be required. These tokens can be configured in such a way that each session + generates a new anti-CSRF token or such that each individual request requires + a new token. It is important that the server track and maintain the status of + each token (in order to reject requests accompanied by invalid ones) and + therefore prevent cyber-criminals from knowing, guessing or reusing them. For + examples of framework specific remediation options, please refer to the + references. + +
Further References:
Finding 285: Unencrypted Password Form (3509195032) [ form password unencrypted ]
Product:
MyApp
Status:
Active, Verified
Severity:
Medium (S2)
Description / Exploit:
The HTTP protocol by itself is clear text, meaning that any data that
is transmitted via HTTP can be captured and the contents viewed.
To keep data private, and prevent it from being intercepted, HTTP
is often tunnelled through either Secure Sockets Layer (SSL), or
Transport Layer Security (TLS). When either of these encryption standards
are used it is referred to as HTTPS. Cyber-criminals will often attempt
to compromise credentials passed from the client to the server using
HTTP. This can be conducted via various different Man-in-The-Middle
(MiTM) attacks or through network packet captures. Arachni discovered
that the affected page contains a password input, however,
the value of the field is not sent to the server utilising HTTPS.
Therefore it is possible that any submitted credential may become
compromised.
Impact:
No impact provided
Systems Vulnerable:
Suggested Mitigation:
The affected site should be secured utilising the latest and most secure + encryption protocols. These include SSL version 3.0 and TLS version 1.2. While + TLS 1.2 is the latest and the most preferred protocol, not all browsers will + support this encryption method. Therefore, the more common SSL is included. + Older protocols such as SSL version 2, and weak ciphers (< 128 bit) should + also be disabled. + +
Further References:
Finding 286: Unencrypted Password Form (2975349655) [ form password unencrypted ]
Product:
MyApp
Status:
Active, Verified
Severity:
Medium (S2)
Description / Exploit:
The HTTP protocol by itself is clear text, meaning that any data that
is transmitted via HTTP can be captured and the contents viewed.
To keep data private, and prevent it from being intercepted, HTTP
is often tunnelled through either Secure Sockets Layer (SSL), or
Transport Layer Security (TLS). When either of these encryption standards
are used it is referred to as HTTPS. Cyber-criminals will often attempt
to compromise credentials passed from the client to the server using
HTTP. This can be conducted via various different Man-in-The-Middle
(MiTM) attacks or through network packet captures. Arachni discovered
that the affected page contains a password input, however,
the value of the field is not sent to the server utilising HTTPS.
Therefore it is possible that any submitted credential may become
compromised.
Impact:
No impact provided
Systems Vulnerable:
Suggested Mitigation:
The affected site should be secured utilising the latest and most secure + encryption protocols. These include SSL version 3.0 and TLS version 1.2. While + TLS 1.2 is the latest and the most preferred protocol, not all browsers will + support this encryption method. Therefore, the more common SSL is included. + Older protocols such as SSL version 2, and weak ciphers (< 128 bit) should + also be disabled. + +
Further References:
Finding 288: Unencrypted Password Form (1042871582) [ form password unencrypted ]
Product:
MyApp
Status:
Active, Verified
Severity:
Medium (S2)
Description / Exploit:
The HTTP protocol by itself is clear text, meaning that any data that
is transmitted via HTTP can be captured and the contents viewed.
To keep data private, and prevent it from being intercepted, HTTP
is often tunnelled through either Secure Sockets Layer (SSL), or
Transport Layer Security (TLS). When either of these encryption standards
are used it is referred to as HTTPS. Cyber-criminals will often attempt
to compromise credentials passed from the client to the server using
HTTP. This can be conducted via various different Man-in-The-Middle
(MiTM) attacks or through network packet captures. Arachni discovered
that the affected page contains a password input, however,
the value of the field is not sent to the server utilising HTTPS.
Therefore it is possible that any submitted credential may become
compromised.
Impact:
No impact provided
Systems Vulnerable:
Suggested Mitigation:
The affected site should be secured utilising the latest and most secure + encryption protocols. These include SSL version 3.0 and TLS version 1.2. While + TLS 1.2 is the latest and the most preferred protocol, not all browsers will + support this encryption method. Therefore, the more common SSL is included. + Older protocols such as SSL version 2, and weak ciphers (< 128 bit) should + also be disabled. + +
Further References:
Finding 290: Unencrypted Password Form (909008784) [ form password unencrypted ]
Product:
MyApp
Status:
Active, Verified
Severity:
Medium (S2)
Description / Exploit:
The HTTP protocol by itself is clear text, meaning that any data that
is transmitted via HTTP can be captured and the contents viewed.
To keep data private, and prevent it from being intercepted, HTTP
is often tunnelled through either Secure Sockets Layer (SSL), or
Transport Layer Security (TLS). When either of these encryption standards
are used it is referred to as HTTPS. Cyber-criminals will often attempt
to compromise credentials passed from the client to the server using
HTTP. This can be conducted via various different Man-in-The-Middle
(MiTM) attacks or through network packet captures. Arachni discovered
that the affected page contains a password input, however,
the value of the field is not sent to the server utilising HTTPS.
Therefore it is possible that any submitted credential may become
compromised.
Impact:
No impact provided
Systems Vulnerable:
Suggested Mitigation:
The affected site should be secured utilising the latest and most secure + encryption protocols. These include SSL version 3.0 and TLS version 1.2. While + TLS 1.2 is the latest and the most preferred protocol, not all browsers will + support this encryption method. Therefore, the more common SSL is included. + Older protocols such as SSL version 2, and weak ciphers (< 128 bit) should + also be disabled. + +
Further References:
Finding 283: Password Field With Auto-Complete (4072242599)
Product:
MyApp
Status:
Active, Verified
Severity:
Low (S3)
Description / Exploit:
In typical form-based web applications, it is common practice for developers
to allow autocomplete within the HTML form to improve
the usability of the page. With autocomplete enabled
(default), the browser is allowed to cache previously entered form
values. For legitimate purposes, this allows the user to quickly
re-enter the same data when completing the form multiple times. When
autocomplete is enabled on either/both the username
and password fields, this could allow a cyber-criminal with access
to the victim’s computer the ability to have the victim’s
credentials automatically entered as the cyber-criminal visits the
affected page. Arachni has discovered that the affected page contains
a form containing a password field that has not disabled autocomplete.
Impact:
No impact provided
Systems Vulnerable:
Suggested Mitigation:
The autocomplete value can be configured in two different
locations. The + first and most secure location is to disable the
autocomplete attribute on + the HTML tag. This will disable . The + second slightly less desirable
option is to disable the autocomplete for all inputs within that + form. An example of disabling autocomplete within the form tag is autocomplete + attribute for
a specific HTML tag. While this may be the less desired +
solution from a security perspective, it may be preferred method for usability +
reasons, depending on size of the form. An example of disabling the +
. + +
autocomplete attribute within a password input tag is
Further References:
Finding 287: Missing 'X-Frame-Options' Header (2388992335)
Product:
MyApp
Status:
Active, Verified
Severity:
Low (S3)
Description / Exploit:
Clickjacking (User Interface redress attack, UI redress attack, UI
redressing) is a malicious technique of tricking a Web user into
clicking on something different from what the user perceives they
are clicking on, thus potentially revealing confidential information
or taking control of their computer while clicking on seemingly innocuous
web pages. The server didn’t return an
X-Frame-Options header which means that this website
could be at risk of a clickjacking attack. The X-Frame-Options HTTP response header can be used to indicate whether or not a browser
should be allowed to render a page inside a frame or iframe. Sites
can use this to avoid clickjacking attacks, by ensuring that their
content is not embedded into other sites.
Impact:
No impact provided
Systems Vulnerable:
Suggested Mitigation:
Configure your web server to include an X-Frame-Options header. + +
Further References:
Finding 289: Password Field With Auto-Complete (392981958)
Product:
MyApp
Status:
Active, Verified
Severity:
Low (S3)
Description / Exploit:
In typical form-based web applications, it is common practice for developers
to allow autocomplete within the HTML form to improve
the usability of the page. With autocomplete enabled
(default), the browser is allowed to cache previously entered form
values. For legitimate purposes, this allows the user to quickly
re-enter the same data when completing the form multiple times. When
autocomplete is enabled on either/both the username
and password fields, this could allow a cyber-criminal with access
to the victim’s computer the ability to have the victim’s
credentials automatically entered as the cyber-criminal visits the
affected page. Arachni has discovered that the affected page contains
a form containing a password field that has not disabled autocomplete.
Impact:
No impact provided
Systems Vulnerable:
Suggested Mitigation:
The autocomplete value can be configured in two different
locations. The + first and most secure location is to disable the
autocomplete attribute on + the HTML tag. This will disable . The + second slightly less desirable
option is to disable the autocomplete for all inputs within that + form. An example of disabling autocomplete within the form tag is autocomplete + attribute for
a specific HTML tag. While this may be the less desired +
solution from a security perspective, it may be preferred method for usability +
reasons, depending on size of the form. An example of disabling the +
. + +
autocomplete attribute within a password input tag is
Further References:
Finding 281: Interesting Response (3585062747) [ interesting response server ]
Product:
MyApp
Status:
Active, Verified
Severity:
Info (S4)
Description / Exploit:
The server responded with a non 200 (OK) nor 404 (Not Found) status code. This is a non-issue, however exotic HTTP response status codes can provide useful insights into the behavior of the web application and assist with the penetration test.
Impact:
No impact provided
Systems Vulnerable:
Suggested Mitigation:
n/a + +
Further References:
Finding 284: HttpOnly Cookie (461231426)
Product:
MyApp
Status:
Active, Verified
Severity:
Info (S4)
Description / Exploit:
HTTP by itself is a stateless protocol. Therefore the server is unable
to determine which requests are performed by which client, and which
clients are authenticated or unauthenticated. The use of HTTP cookies
within the headers, allows a web server to identify each individual
client and can therefore determine which clients hold valid authentication,
from those that do not. These are known as session cookies. When
a cookie is set by the server (sent the header of an HTTP response)
there are several flags that can be set to configure the properties
of the cookie and how it is to be handled by the browser. The HttpOnly flag assists in the prevention of client side-scripts (such as JavaScript)
accessing and using the cookie. This can help prevent XSS attacks
targeting the cookies holding the client’s session token (setting
the
HttpOnly flag does not prevent, nor safeguard against
XSS vulnerabilities themselves).
Impact:
No impact provided
Systems Vulnerable:
Suggested Mitigation:
The initial step to remedy this would be to determine whether any client-side +
scripts (such as JavaScript) need to access the cookie and if not,
set the +
HttpOnly flag. Additionally, it should be noted that
some older browsers are + not compatible with the HttpOnly flag, and therefore setting this flag will + not protect those clients
against this form of attack. + +
Further References:
Findings
HttpOnly Cookie (461231426)
Product:
MyApp
Status:
Active, Verified
Severity:
Info (S4)
Description / Exploit:
HTTP by itself is a stateless protocol. Therefore the server is unable
to determine which requests are performed by which client, and which
clients are authenticated or unauthenticated. The use of HTTP cookies
within the headers, allows a web server to identify each individual
client and can therefore determine which clients hold valid authentication,
from those that do not. These are known as session cookies. When a
cookie is set by the server (sent the header of an HTTP response) there
are several flags that can be set to configure the properties of the
cookie and how it is to be handled by the browser. The HttpOnly flag assists in the prevention of client side-scripts (such as JavaScript)
accessing and using the cookie. This can help prevent XSS attacks targeting
the cookies holding the client’s session token (setting the
HttpOnly flag does not prevent, nor safeguard against
XSS vulnerabilities themselves).
Impact:
No impact provided
Systems Vulnerable:
Suggested Mitigation:
The initial step to remedy this would be to determine whether any client-side +
scripts (such as JavaScript) need to access the cookie and if not,
set the +
HttpOnly flag. Additionally, it should be noted that some
older browsers are + not compatible with the HttpOnly flag, and therefore setting this flag will + not protect those clients
against this form of attack. + +
Further References:
Finding ID:
Finding 284
Interesting Response (3585062747) [ interesting response server ]
Product:
MyApp
Status:
Active, Verified
Severity:
Info (S4)
Description / Exploit:
The server responded with a non 200 (OK) nor 404 (Not Found) status code. This is a non-issue, however exotic HTTP response status codes can provide useful insights into the behavior of the web application and assist with the penetration test.
Impact:
No impact provided
Systems Vulnerable:
Suggested Mitigation:
n/a + +
Further References:
Finding ID:
Finding 281