- SQL Injections
- Use prepared statements - known as parameterized queries.
- Command Injection: Ability to execute Operating system commands using characters such as (; $ |)
- Do rigorous input validation.
- Check input length
- validate against the allowlist of valid input values
- check if the input contains only alpha numeric and does not contain some special characters.
- XML Injection: exploits parsing of untrusted XML entities by a weakly configured XML parser.
- disable parsing of XML eXternal Entities (XXE) and Document Type Definition.
- disable parsing of external general entities and external parameter entities
- Directory Traversal: When we see we are passing a directory structure or file name, we can edit the parameter to try and fetch other system files.
- To avoid it, check the path of the file constructed is appropriate.
- Weak Randomness: here session token generated was not random enough. it was dependent on the current time stamp.
- Use a random number generated that can not be predicted.
- Session Fixation: exploits applications' failure to generate new Session ID on every time a use authenticates.
when session id is passed as a parameter because of using legacy web framework or custom sessions management library - session id must be refreshed upon each login, logout, and password reset.
- Reflected XSS: The ability to inject and run untrusted data such as malicious javascript code or HTML code into the victim's browser is called a cross-site scripting attack.
- Rendering user-provided input into a web page is a common source for cross-site scripting.
- Attack Surface: Process of analyzing an application's core functionality, business logic, and control flow to identify potential inputs or vectors through which an attacker could try and enter the application environment.
- https://www.sourceyard.com/bob/blender/issues?query=<script>document.location = 'www.src-yard.com';</script> : example where javascript makes redirect to malicious fake website
- If no issues were found, the search string is displayed on the page. Here the developers use the <%= %> tag to render the value of searchParameter.
- However, the <%= %> tag displays the value without any processing. Most importantly, it does not escape reserved HTML characters. Therefore, Bob's search string <script>document.location = 'www.source-yard'<script> is included in the generated web page and his script will be executed whenever that page is loaded.
Solution : - In this modified code, we use the <c:out> tag to render the value of searchParameter. This tag automatically escapes reserved HTML characters.
- In addition, we explicitly activate the option of escaping XML tags. Bob's search string will therefore be rendered as <script>document.location = 'www.source-yard'</script>, which prevents his script from being executed when the page is loaded
- DOM XSS :
function escapeHTML(html) {return html.replace(/&/g, '&').replace(/</g, '<').replace(/>/g, '>').replace(/"/g, '"').replace(/'/g, ''');}- Stored Cross-Site Scripting
- What is a zero-day vulnerability?Zero-day is a security flaw in the software, hardware, or firmware that is unknown to the party or parties responsible for patching or otherwise fixing the flaw.
- The main difference between the <c:out> tag and the expression tag <%= %> is what they additionally do. In particular, the <c:out> tag automatically escapes special characters like <, > and " in its value, while the expression tag <%= %> does not.
- Therefore, using a <c:out> tag when displaying the ticket description, the <script> tags will be escaped. Bob's ticket description will be evaluated to a string starting with <script>, thus rendering his script ineffective.
- Forced Browsing
- What is LinkFinder?
- LinkFinder is an open-source python script used to discover API endpoints, URL resources and query parameters within minified JavaScript files. The script uses a combination of regular expressions to gather hidden URLs and application routes which can then be used by security researchers to further test for vulnerabilities.
- This ability to enumerate and gain access to restricted pages or other sensitive resources by invoking the URL directly is known as a Forced Browsing vulnerability.
In order to mitigate against Forceful Browsing vulnerabilities, developers must ensure appropriate permissions and access-control settings are applied for every URL and web resource in their application.
Further, application owners must remove all private URL routes used for development and testing in production environments.
For example, if an application has a private URL route for accessing an internal-only web interface or API, developers must scope the private URL routes so that only users with the appropriate access rights can access these interfaces.
Finally, developers must protect application staging and test environments by restricting their access to specific IP ranges or addresses, thereby preventing search engines such as Shodan from discovering and indexing these assets.
- Leftover debug code
- Developers often forget to adequately protect their application environments from being indexed by Google and other search engines. This often results in search engines being able to discover and index development, testing, staging sites, or other sensitive assets that should otherwise be denied access by search engines.
In order to mitigate against deploying active debugging code in production instances, developers must ensure appropriate permissions and access-control settings are applied for accessing such features. Alternatively, development teams can add conditional variables to remove debugging code when deploying in production and staging environments.
Further, development teams must proactively identify and remove developer comments that reference sensitive information including internal URLs, API endpoints, or test credentials before deploying the application.
Finally, developers must protect application staging and test environments by restricting their access to specific IP ranges or addresses, thereby preventing search engines such as Google from discovering and indexing these assets.
- PII data in URL
- What is PII?
- Personally Identifiable Information (PII) is a legal term used to define any information that can be used by organizations on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context.
- A log monitoring application such as Splunk to monitor the application logs.
- A third-party web analytics software such as Google Analytics for site traffic tracking.
- In both instances, Upbank's customer PII data may proliferate to third party systems, leaking sensitive customer details and personal data to third-party sites, including advertisers and third-party analytics companies.
Answer : - developers must ensure personally identifiable data is not transmitted via URL query parameters.
- It should be noted that the use of HTTPS protocol is not sufficient to protect against PII exposure in URL parameters since HTTPS cannot prevent data from being logged in:
- Web server logs
- Reverse proxy servers
- Google Analytics and similar frameworks
- Browser History
- Token exposure in URL
- Exists the risk of passing sensitive data such as API tokens, authentication credentials or session cookies in URL parameters
- Risk occurs when :
- A log monitoring application such as Splunk to monitor the application logs.
- A third-party analytics engine such as Elasticsearch or Logstash
- To effectively mitigate against exposure of API tokens in URLs, developers should use HTTP headers for transmitting API tokens. Examples of these headers include the following: Authorization: <token_value>
- User Enumeration
User Enumeration refers to the ability to probe an application to check whether a user exists. This is usually disclosed by differences in the application's response to submitted credentials, either in response messages or in response times. Once it is possible to confirm whether a user name or email is registered, a brute force approach can automatically guess valid users, which can then be used in other exploits. - Could not reset the password because there is no registered user with that e-mail address.
- The above message is indicative of a User Enumeration vulnerability since the application returns an error message indicating that the submitted account username bob@livemail.com is not valid or registered on the CloudGraph application
Answer : - To effectively mitigate against User Enumeration attacks, developers must display a generic response message regardless of whether or not the username, email or account is valid.
- Vertical Privilege Escalation
- Vertical Privilege Escalation attack in which a malicious user gains access to a privileged account.
- However, the attack is not limited to Account Management functions and can potentially occur in any application feature where untrusted parameter values are passed to the application without performing adequate authentication and authorization checks.
Answer : - A proper access control policy is required.
- One must cross-check the credentials passed if they are appropriate.
- Header Injection
- if the application relies on the value of the Host header for sending links, it could be vulnerable to Host Header Injection attacks.
- The ability to manipulate an application's response by setting the HTTP Host header to arbitrary values is known as a Host Injection or Host Header Poisoning attack.
- It then uses the Host value to create the link URL, without further validation. There is no intermediate step that checks whether the Host is actually the one we expect, or whether someone tinkered with the request.
Answer: - In order to effectively mitigate against Header Injection attacks, developers must ensure all incoming HTTP headers are properly sanitized to prevent malicious header values from being included in the response or backend business logic.
- This can be achieved by implementing an allowlist of allowed hostnames and subdomains, which can be used to prevent malicious hostnames from being included in the response.
- Clickjacking
- Analyzing Bob's malicious webpage in the previous step revealed how the Accept button of the visible Cookie Consent page overlaps exactly with the Disable two-step verification button of CoinPay's Settings page.
- This technique whereby a webpage is loaded via an iframe and subsequently covered with deceptive content to trick a user into invoking an action on the underlying webpage is known as a Clickjacking attack.
Answer: - To mitigate against Clickjacking attacks, developers must configure their web servers or load balancers to include X-Frame-Options or Content-Security-Policy header.
- Both X-Frame-Options andContent-Security-Policy response headers define whether or not a browser should be allowed to embed or render a page in an <iframe> element. For example, setting X-Frame-Options: deny will prevent browsers from rendering your web application in an <iframe> element.
- Horizontal Privilege Escalation
- Horizontal Privilege Escalation attack in which a malicious actor gains access to a user account or performs unauthorized actions on behalf of the user. Further, such vulnerabilities are not limited to a particular feature e.g. card deletion and may manifest in any functionality where untrusted parameter values are passed to the application without performing adequate authentication and authorization checks.
Answer : - Doing proper authorization checks and validations.
- Insecure URL Redirect
- This ability to submit a user-supplied URL or domain name that causes a redirection to an arbitrary external domain is known as a URL redirection attack.
Answer: - To mitigate the risk of malicious actors exploiting URL redirects in the way that Bob did, application developers must always verify the URL that the user will be redirected or forwarded to, especially if the URL parameter can be changed or tampered with on the client-side. This is especially important for applications that use dynamic content, such as web pages, that are not hosted by a single domain.
- However, in our example, we can eliminate the need to perform URL verification by performing a server-side hostname lookup to securely redirect the user to the login webpage.
- Basically, do not make redirect url user paramter.
- Components with known Vulnerability
- To effectively mitigate against component-based vulnerabilities, developers must regularly audit software components and their dependencies, making sure the third-party libraries and software dependencies are always up-to-date.
- Server-side Request Forgery
SSRF vulnerabilities are most commonly encountered in functionality associated with:
PDF generation e.g. Generate PDF reports, Credit Card statements;
- File Upload e.g. Uploading scanned documents, image files etc.
- By simply changing the AWS S3 bucket link to a different URL resource, Bob manages to trick the preview applet into fetching and loading an external image resource.
- It's important to note that the CapitalTen application server made the HTTP request to fetch the image URL and rendered the image.
- This ability to manipulate a web application into sending unauthorized requests to a third-party site or resource is known as Server Side Request Forgery (SSRF).
- Although SSRF issues may appear to pose a limited risk, attackers can get creative with these vulnerabilities to make requests to non-public URLs that may expose sensitive data.
- One such service commonly exploited by attackers in third-party cloud environments is a REST-based web service known as cloud metadata endpoint. If configured, a metadata endpoint provides programmatic access to a cloud server’s system configuration, networking details, authentication access keys, etc.
- Cross-Site Request Forgery
- happens by clicking malicious link that is running static iframe when clicked.
Answer:
- A number of effective methods exist for both the prevention and mitigation of CSRF attacks. Among the most common mitigation methods is to embed unique random tokens, also known as anti-CSRF tokens for every HTTP request and response cycle which are subsequently checked and verified by the server.
- Since a potential attacker can never guess the value of these tokens, anti-CSRF tokens provide a strong defense against CSRF attacks. Further, most modern frameworks provide inbuilt CSRF methods for generating, storing and validating such tokens. However, it is important that this functionality is active and configured correctly across the entire application.
To effectively mitigate against Document Object Model (DOM) based cross-site scripting vulnerabilities, developers must sanitize all untrusted data that is dynamically injected into the DOM.
For example, if client-side JavaScript is used to manipulate the content, structure, or style of a document's DOM element with user-supplied data, such input strings must be sanitized (encoded or escaped) for safe insertion into a document's DOM.
Additionally, DOM objects that may be influenced by the user (attacker) should be carefully reviewed and escaped, including (but not limited to):
document.URL
document.URLUnencoded
document.location (and child properties)
document.referrer
window.location (and child properties)
X-API-Key: <token_value>
ProjectName-Api-Key: <token_value>
