Closed cwong-scw closed 4 years ago
Stored cross-site scripting vulnerabilities happen when unescaped input is displayed by the application after successful storage in persistence layers (e.g. database or cache). When HTML or script is included in the input that is stored in the database, and is then rendered into a page without escaping or encoding, it will be processed by a user's browser as HTML or script and can alter the appearance of the page or execute malicious scripts in their user context.
Find the instances in the application where external input is saved to the persistence layer and subsequently displayed to users. Try to trace each value all the way from input to display and work out if any escaping or encoding is applied to prevent these values from being treated as raw HTML or script once it is written to the page. Pay special attention to the context of where the values are being written into a page as different contexts may have different encoding requirements. For example, a value written into a HTML tag attribute will require different encoding to a value written into a HTML tag value.
Stored cross-site scripting vulnerabilities happen when unescaped input is displayed by the application after successful storage in persistence layers (e.g. database or cache). When HTML or script is included in the input that is stored in the database, and is then rendered into a page without escaping or encoding, it will be processed by a user's browser as HTML or script and can alter the appearance of the page or execute malicious scripts in their user context.
Find the instances in the application where external input is saved to the persistence layer and subsequently displayed to users. Try to trace each value all the way from input to display and work out if any escaping or encoding is applied to prevent these values from being treated as raw HTML or script once it is written to the page. Pay special attention to the context of where the values are being written into a page as different contexts may have different encoding requirements. For example, a value written into a HTML tag attribute will require different encoding to a value written into a HTML tag value.
Code injection happens when an application insecurely accepts input that is subsequently used in a dynamic code evaluation call. If insufficient validation or sanitisation is performed on the input, specially crafted inputs may be able to alter the syntax of the evaluated code and thus alter execution. In a worst case scenario, an attacker could run arbitrary code in the server context and thus perform almost any action on the application server.
Try to identify instances where external input is subsequently used in a dynamic code evaluation call and identify the code context in which each input is used. Carefully review the data flow of these inputs and determine if appropriate filtering or encoding is being performed. You may need to look up language reference material to identify the language-specific special characters that any validation or sanitisation logic will need to account for.
Reflected cross-site scripting vulnerabilities occur when unescaped input is displayed in the resulting page displayed to the user. When HTML or script is included in the input, it will be processed by a user's browser as HTML or script and can alter the appearance of the page or execute malicious scripts in their user context.
Find the instances in the application where external input is displayed to users. Try to trace each value all the way from input to display and work out if any escaping or encoding is applied to prevent these values from being treated as raw HTML or script once it is written to the page. Pay special attention to the context of where the values are being written into a page as different contexts may have different encoding requirements. For example, a value written into a HTML tag attribute will require different encoding to a value written into a HTML tag value.
Reflected cross-site scripting vulnerabilities occur when unescaped input is displayed in the resulting page displayed to the user. When HTML or script is included in the input, it will be processed by a user's browser as HTML or script and can alter the appearance of the page or execute malicious scripts in their user context.
Find the instances in the application where external input is displayed to users. Try to trace each value all the way from input to display and work out if any escaping or encoding is applied to prevent these values from being treated as raw HTML or script once it is written to the page. Pay special attention to the context of where the values are being written into a page as different contexts may have different encoding requirements. For example, a value written into a HTML tag attribute will require different encoding to a value written into a HTML tag value.
XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. 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.
_Credits: OWASP Top 10 2017_
Server-Side Request Forgery (SSRF) vulnerabilities are caused when an attacker can supply or modify a URL that reads or sends data to the server. The attacker can create a malicious request with a manipulated URL, when this request reaches the server, the server-side code executes the exploit URL causing the attacker to be able to read data from services that shouldn't be exposed.
Look for places where URLs are handled such as calling resources from external servers, requests that are sent to external services or custom webhooks. Additionally, check where the user can specify custom URLs.
Fixes SSRF and Stored XSS issues