0% found this document useful (0 votes)
93 views16 pages

Security Vulnerabilities

The document outlines several potential security vulnerabilities including: remote command injection, missing anti-CSRF tokens, application error disclosures exposing sensitive data, cookies without proper flags, private IP exposure, cross-domain script inclusion, missing security headers, and information disclosures in URLs and comments. The vulnerabilities could allow attacks like session hijacking, data theft, and further exploitation of systems if not addressed.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
93 views16 pages

Security Vulnerabilities

The document outlines several potential security vulnerabilities including: remote command injection, missing anti-CSRF tokens, application error disclosures exposing sensitive data, cookies without proper flags, private IP exposure, cross-domain script inclusion, missing security headers, and information disclosures in URLs and comments. The vulnerabilities could allow attacks like session hijacking, data theft, and further exploitation of systems if not addressed.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 16

Security vulnerabilities

Remote OS Command Injection


Multiple X-Frame-Options Header Entries
• X-Frame-Options: DENY
• X-Frame-Options: SAMEORIGIN
• X-Frame-Options: ALLOW-FROM https://example.com/
• DENY
A browser receiving content with this header field MUST NOT display this content in any
frame.
• SAMEORIGIN
• A browser receiving content with this header field MUST NOT display this content in any
frame from a page of different origin than the content itself.
• If a browser or plugin cannot reliably determine whether or not the origin of the content and
the frame are the same, this MUST be treated as "DENY".
Absence of Anti-CSRF Tokens
Application Error Disclosure
• This page contains an error/warning message that may disclose sensitive information like the
location of the file that produced the unhandled exception. This information can be used to
launch further attacks against the web application. The alert could be a false positive if the
error message is found inside a documentation page.
• Review the source code of this page. Implement custom error pages. Consider implementing
a mechanism to provide a unique error reference/identifier to the client (browser) while
logging the details on the server side and not exposing them to the user
• This vulnerability means that the user’s data is not properly protected by the application. It
may be possible for the attacker to access all the information about your application. There is
a threat of sensitive information disclosure like internal server configuration, credentials of
API keys, resources location and many more.
• This information can be used to perform further attacks against your web application.
Cookie No HttpOnly Flag
• A cookie has been set without the HttpOnly flag, which means that the cookie can be
accessed by JavaScript.
• If a malicious script can be run on this page then the cookie will be accessible and can be
transmitted to another site. If this is a session cookie then session hijacking may be possible.
<httpCookies httpOnlyCookies="true" …>
• Ensure that the HttpOnly flag is set for all cookies.
• According to Michael Howard, Senior Security Program Manager in the Secure Windows
Initiative group at Microsoft, the majority of XSS attacks target theft of session cookies. A
server could help mitigate this issue by setting the HttpOnly flag on a cookie it creates,
indicating the cookie should not be accessible on the client.
• If a browser that supports HttpOnly detects a cookie containing the HttpOnly flag, and client
side script code attempts to read the cookie, the browser returns an empty string as the
result. This causes the attack to fail by preventing the malicious (usually XSS) code from
sending the data to an attacker’s website.
Cookie without SameSite Attribute
• A cookie has been set without the SameSite attribute, which means that the cookie can be
sent as a result of a 'cross-site' request. The SameSite attribute is an effective counter
measure to cross-site request forgery, cross-site script inclusion, and timing attacks.
• Ensure that the SameSite attribute is set to either 'lax' or ideally 'strict' for all cookies.
• Strict Value
• The Strict value is the most restrictive usage of SameSite, allowing the browser to send the cookie
only to first-party context without top-level navigation. In other words, the data associated with the
cookie will only be sent on requests matching the current site shown on the browser URL bar. The
cookie will not be sent on requests generated by third-party websites. This value is especially
recommended for actions performed at the same domain. However, it can have some limitations
with some session management systems negatively affecting the user navigation experience. Since
the browser would not send the cookie on any requests generated from a third-party domain or
email, the user would be required to sign in again even if they already have an authenticated
session.
• Lax Value
• The Lax value is less restrictive than Strict. The cookie will be sent if the URL equals the cookie’s
domain (first-party) even if the link is coming from a third-party domain. This value is considered by
most browsers the default behavior since it provides a better user experience than the Strict value.
It doesn’t trigger for assets, such as images, where cookies might not be needed to access them.
Cookie Without Secure Flag
• A cookie has been set without the secure flag, which means that the cookie can be accessed
via unencrypted connections.
• Whenever a cookie contains sensitive information or is a session token, then it should always
be passed using an encrypted channel. Ensure that the secure flag is set for cookies
containing such sensitive information.
• The Secure attribute tells the browser to only send the cookie if the request is being sent over
a secure channel such as HTTPS. This will help protect the cookie from being passed in
unencrypted requests. If the application can be accessed over both HTTP and HTTPS, an
attacker could be able to redirect the user to send their cookie as part of non-protected
requests
Incomplete or No Cache-control Header Set
• Whenever possible ensure the cache-control HTTP header is set with no-cache, no-
store, must-revalidate.

• The no-cache directive means that a browser may cache a response, but must first
submit a validation request to an origin server.
Cache-Control: no-cache
• The no-store directive means browsers aren’t allowed to cache a response and must
pull it from the server each time it’s requested. This setting is usually used
for sensitive data, such as personal banking details.
Cache-Control: no-store
• The must-revalidate response directive indicates that the response can be stored in
caches and can be reused while fresh. If the response becomes stale, it must be
validated with the origin server before reuse.
Cache-Control: max-age=604800, must-revalidate
Cross-Domain JavaScript Source File
Inclusion
• The page includes one or more script files from a third-party domain.
• Ensure JavaScript source files are loaded from only trusted sources, and the sources can't be
controlled by end users of the application.
X-Content-Type-Options Header Missing
• The missing "X-Content-Type-Options" header enables a browser to perform MIME type
sniffing when the Content-Type header is not set or its value seems inappropriate. In other
words, when the browser gets the response from the server it tries to figure out on its own
what is the type of the content and how to handle it. In certain circumstances that can lead
to serious security issues (XSS attack).
• For example, if we have an application that allows an upload of jpg files, an attacker may
upload a file with jpg extension being in fact an html file with malicious js script inside. Some
other user may want to display the image in his browser. The browser gets the file with
Content-Type=image/jpg and finds out that content type is inappropriate. If the MIME type
sniffing is enabled, the browser handles the file as html and executes the malicious js script.
On the other hand, if the MIME type sniffing is disabled by setting the "X-Content-Type-
Options" header, the browser displays an error message and the script is not executed.

X-Content-Type-Options=nosniff
Private IP Disclosure
• A private IP (such as 10.x.x.x, 172.x.x.x, 192.168.x.x) or an Amazon EC2 private hostname (for
example, ip-10-0-56-78) has been found in the HTTP response body. This information might
be helpful for further attacks targeting internal systems
• Discovering the private addresses used within an organization can help an attacker in carrying
out network-layer attacks aiming to penetrate the organization's internal infrastructure.
• There is not usually any good reason to disclose the internal IP addresses used within an
organization's infrastructure. If these are being returned in service banners or debug
messages, then the relevant services should be configured to mask the private addresses. If
they are being used to track back-end servers for load balancing purposes, then the
addresses should be rewritten with innocuous identifiers from which an attacker cannot infer
any useful information about the infrastructure.
Information Disclosure - Sensitive
Information in URL
Information Disclosure - Suspicious
Comments
Loosely Scoped Cookie
Timestamp Disclosure - Unix

You might also like