- SQL Injection: SQL injection is the placement of malicious code in SQL statements, via web page input. It is a technique targeting database.
- XSS (Cross Site Scripting):
- XSS is an attack where malicious scripts are injected
- generally in the form of a browser side script.
- The end user’s browser thinks that script came from trusted source and execute the script.
- The malicious script can access any cookies, session tokens
- These scripts can even rewrite the content of the HTML page
- Broken Authentication and Session Management:
- Broken authentication: Any flawed credential management functions like password change, forgot password, remember my password and account update are vulnerable for this attack.
- if the session tokens are not properly protected, an attacker can hijack an active session and assume the identity of a user. Then can perform any activity including changing password.
- Protect by : Review every available mechanism for changing a user’s credentials to ensure that only an authorized user can change them, Password strength, defined number of login attempts , passwords must be stored in either hashed or encrypted, encrypt the entire login transaction using something like SSL/TSL, entire session should be protected via SSL/TSL, Authentication and session data should never be submitted as part of a GET but should use POST method, Authentication pages should be marked with all varieties of the no cache tag, Trust Relationships : Each component should authenticate itself to any other component it is interacting with.
- Insecure Direct Object Reference:
- Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object.
- Such resources can be database entries belonging to other users, files in the system, and more.
- This is caused by the fact that the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.
- Cross Site Request Forgery(CSRF): Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated.
- CSRF attacks specifically target state-changing requests, not theft of data.
- It inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf.
- For example sending a link via email or chat clicking on which can purchasing something, or change victim's email address or password
- CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, and Hostile Linking. Microsoft refers to this type of attack as a One-Click attack
- https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
- Security Misconfiguration: Security misconfiguration can happen at any level of an application stack, including the network services, platform, web server, application server, database, frameworks, custom code, and pre-installed virtual machines, containers, or storage. Automated scanners are useful for detecting misconfigurations, use of default accounts or configurations, unnecessary services, legacy options, etc https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration
- Example 1: Directory listing is not disabled on the server. An attacker discovers they can simply list directories.
- Example 2:The application server's configuration allows detailed error messages, e.g. stack traces, to be returned to users. This potentially exposes sensitive information
- Insecure Cryptographic Storage: Attackers typically don’t break the crypto. They break something else, such as find keys, get cleartext copies of data, or access data via channels that automatically decrypt. The most common flaw in this area is simply not encrypting data that deserves encryption.
- Example: An application encrypts SSN numbers in a database to prevent exposure to end users. However, the database is set to automatically decrypt queries against the SSN column, allowing an SQL injection flaw to retrieve all the SSN in cleartext. The system should have been configured to allow only back end applications to decrypt them, not the front end web application.
- Failure to restrict URL Access: Attacker, who is an authorized system user, simply changes the URL to a privileged page. Is access granted? Anonymous users could access private pages that aren’t protected.
- Answer this question to yourself: Is this URL supposed to be accessible to ANY authenticated user? If not, is an authorization check made to ensure the user has permission to access that page?
- Insufficient Transport Layer Protection: Consider anyone who can monitor the network traffic of your users. If the application is on the internet, who knows how your users access. Applications frequently do not protect network traffic. They may use SSL/TLS during authentication, but not elsewhere, exposing data and session IDs to interception. Expired or improperly configured certificates may also be used. Make sure these things are taken care:
- Require SSL for all sensitive pages. Non-SSL requests to these pages should be redirected to the SSL page.
- Set the ‘secure’ flag on all sensitive cookies.
- Configure your SSL provider to only support strong (e.g., FIPS 140-2 compliant) algorithms.
- Ensure your certificate is valid, not expired, not revoked, and matches all domains used by the site.
- Backend and other connections should also use SSL or other encryption technologies.
- Unvalidated Redirects and Forwards: Attacker links to unvalidated redirect and tricks victims into clicking it. Applications frequently redirect users to other pages, or use internal forwards in a similar manner. Sometimes the target page is specified in an unvalidated parameter, allowing attackers to choose the destination page.
- Example #1: The application has a page called “redirect.jsp” which takes a single parameter named “url”. The attacker crafts a malicious URL that redirects users to a malicious site that performs phishing and installs malware.
- Prevention can be done Simply avoid using redirects and forwards. Or if used at least don’t involve user parameters in calculating the destination.