The OWASP Top 10 Web Application Security Risks are:
1: Injection
2: Cross-Site Scripting (XSS)
3: Broken Authentication and Session Management
4: Insecure Direct Object References
5: Cross-Site Request Forgery (CSRF)
6: Security Misconfiguration
7: Insecure Cryptographic Storage
8: Failure to Restrict URL Access
9: Insufficient Transport Layer Protection
10: Unvalidated Redirects and Forwards
1: Injections
Injecting invalid data in any input box. It may be username, password, phno etc. If it shows some error in that, then definetely there is some vulnerabiltiy in that site. We can use SQL injection to login the page without the actual user creditionals.
SQL injection is an attack in which malicious code is inserted into strings that are later passed to an instance of SQL Server for parsing and execution. Any procedure that constructs SQL statements should be reviewed for injection vulnerabilities because SQL Server will execute all syntactically valid queries that it receives. Even parameterized data can be manipulated by a skilled and determined attacker. To know more about this click on SQL injection Attack
2: Cross-Site Scripting (XSS)
Cross Site Scripting (also known as XSS or CSS) is generally believed to be one of the most common application layer hacking techniques.
Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise begin and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page.
3: Broken Authentication and Session Management
Authentication and session management includes all aspects of handling user authentication and managing active sessions. Authentication is a critical aspect of this process, but even solid authentication mechanisms can be undermined by flawed credential management functions, including password change, forgot my password, remember my password, account update, and other related functions. Because “walk by” attacks are likely for many web applications, all account management functions should require reauthentication even if the user has a valid session id.
User authentication on the web typically involves the use of a userid and password. Stronger methods of authentication are commercially available such as software and hardware based cryptographic tokens or biometrics, but such mechanisms are cost prohibitive for most web applications. A wide array of account and session management flaws can result in the compromise of user or system administration accounts. Development teams frequently underestimate the complexity of designing an authentication and session management scheme that adequately protects credentials in all aspects of the site. Web applications must establish sessions to keep track of the stream of requests from each user. HTTP does not provide this capability, so web applications must create it themselves. Frequently, the web application environment provides a session capability, but many developers prefer to create their own session tokens. In either case, if the session tokens are not properly protected, an attacker can hijack an active session and assume the identity of a user. Creating a scheme to create strong session tokens and protect them throughout their lifecycle has proven elusive for many developers. Unless all authentication credentials and session identifiers are protected with SSL at all times and protected against disclosure from other flaws, such as cross site scripting, an attacker can hijack a user’s session and assume their identity.
An attacker can modify the internal implementation object in an attempt to abuse the access controls on this object. When the attacker does this they may have the ability to access functionality that the developer didn’t intend to expose access to.
5: Cross-Site Request Forgery (CSRF)
A Cross-site request forgery attack, also known as CSRF or XSRF (pronounced sea-surf) is the less well known, but equally dangerous, cousin of the Cross Site Scripting (XSS) attack. Yeah, they come from a rough family.
CSRF is a form of confused deputy attack. Imagine you’re a malcontent who wants to harm another person in a maximum security jail. You’re probably going to have a tough time reaching that person due to your lack of proper credentials. A potentially easier approach to accomplish your misdeed is to confuse a deputy to misuse his authority to commit the dastardly act on your behalf. That’s a much more effective strategy for causing mayhem!
In the case of a CSRF attack, the confused deputy is your browser. After logging into a typical website, the website will issue your browser an authentication token within a cookie. Each subsequent request to sends the cookie back to the site to let the site know that you are authorized to take whatever action you’re taking.
Suppose you visit a cryptographic website soon after visiting your bank website. Your session on the previous site might still be valid (though most bank websites guard against this carefully). Thus, visiting a carefully crafted malicious website (perhaps you clicked on a spam link) could cause a form post to the previous website. Your browser would send the authentication cookie back to that site and appear to be making a request on your behalf, even though you did not intend to do so.
6: Security Misconfiguration
Safeguarding your website from malicious users and attacks is important, regardless of what type of site you have or how many visitors your site receives. Security misconfiguration, or poorly configured security controls, could allow malicious users to change your website, obtain unauthorized access, compromise files, or perform other unintended actions.
7 : Insecure Cryptographic Storage
Insecure cryptographic storage occurs when an application doesn’t securely encrypt it’s sensitive data when it is stored into a database.
Simply stated, insecure cryptographic storage occurs when one of following happens: * The developers don’t encrypt the data that is being stored in the database. * The developers do encrypt the data being stored in the database, but they rely on encryption methods they have developed. (Also known as home-grown cryptography)
After reading these two points you may say, “only an idiot wouldn’t encrypt sensitive data being stored in the database.” I refer you to number two in the list above.
If you think you are smart enough to write your own cryptographic algorithms, you my friend, are the idiot.
The main business concern with not encrypting sensitive data is that it can lead to confidentiality loss. All companies are concerned with unauthorized individuals viewing their sensitive data. In addition, encrypting sensitive data is be a regulatory compliance
The main idea of this kind of attack is try to discover resources which are not published but they can be accesed using “forced browsing”. The purpose of this attack is quite similar to Insecure Direct Object Reference so both have the same goal: get unauthorized access to resources
Between the resources an attacker usually gets access we find the following:
1. Pages with admin purposes functionality
2. Pages that we should not access with the profile we logged in
3. Different kind of files (pdf, xml, exe)
4. Code that evaluate privileges on the client but not on the server. With this option the access is not directly to the URL using forced browsing but a wrong check of the privileges permit us to access pages that should not be allowed.
5. Code that enforces an access control policy but is out of date or insufficient so all users can access to the resources controlled by that policy.
9: Insufficient Transport Layer Protection
Sensitive data, such as credit card numbers or other personal information, must be secured with strong encryption during transit from a visitor’s browser to the Web server. If the data isn’t encrypted, a malicious user might intercept and view the information.
SSL certificates help prevent insufficient transport layer protection by encrypting everything into an undecipherable format that can only be deciphered with the correct decryption key, which is installed on the website.
While an SSL certificate helps secure data during transit, sensitive data might still be vulnerable if it’s not installed properly or it doesn’t secure all sensitive data. Consider securing your entire website with an SSL certificate. If that’s not possible, secure all access-restricted pages, and cookies or session information that could contain sensitive details.
10: Unvalidated Redirects and Forwards
Session stealing based on URL redirection or forwarding is a weakness, which in most cases requires the victims interaction (social engineering). The conduction of such an attack is relatively simple. The web application remembers the URL, which was requested from a client web browser. After a successful login the user is redirected to the remembered URL. However, if the application does not check the validity of the former URL then a user might get redirected to a site, which collects a users session or asks once more for username and password (EX : Phisihing Site)
No comments:
Post a Comment