1. SQL Injection Attacks
A SQL injection attack consists of
insertion or "injection" of a SQL query via the input data from
the client to the application. A successful SQL injection exploit can read
sensitive data from the database, modify database data Insert/ Update/ Delete
Defenses:
1: Use of Prepared Statements (with Parameterized Queries)
2: Use of Stored Procedures
3: White List Input Validation
4: Escaping All User Supplied Input
2. Broken Authentication & Session Management
Authentication is a critical part of any application, even solid authentication
mechanisms can be undermined by flawed credential management functions, including
password policy, password change, forgot my password, remember my password, account
update, and other related functions.
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. If session identifiers are not properly protected,
an attacker can hijack an active session and assume the identity of a user.
Defenses:
1. Password Strength
2. Password Use
3. Password Change Controls
4. Password Storage
5. Protecting Credentials in Transit
6. Session ID Protection
3. Cross-Site Scripting (XSS) Attacks
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious
scripts are injected into trusted web sites generally in the form of a browser
side script, to a different end 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 the
browser and used with that site.
Defense:
1.Never accept actual JavaScript code from an untrusted source and then run it
2. HTML Escape Before Inserting Untrusted Data into HTML Element Content
3. JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values
4. CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML
Style Property Values
5. URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values
6. Use HTTPOnly cookie flag
4. Insecure Direct Object References
Insecure Direct Object References occur when an application provides direct access
to objects based on user-supplied input. As a result of this vulnerability attackers
can bypass authorization and access resources in the system directly, for example
database records or files.
Defense:
1. Use per user or session indirect object references
2. Check access
5.Security Misconfiguration
Security Misconfiguration arises when Security settings are defined, implemented,
and maintained as defaults. Good security requires a secure configuration defined
and deployed for the application, web server, database server, and platform. It is
equally important to have the software up to date.
1. If Directory listing is not disabled on the server
2. App server configuration allows stack traces to be returned to users
3. App servers usually come with sample apps that are not well secured. If not
removed from production server would result in compromising your server
6.Sensitive Data Exposure
Sensitive data exposure vulnerabilities can occur when an application does not
adequately protect sensitive information from being disclosed to attackers.
Defense
1. Encrypt the data and define accessibility
2. Use SSL or TSL to ensure transport layer security
3. Disable caching for pages that contain sensitive data.
Scenario #1: An application encrypts credit card numbers in a database using automatic
database encryption. However, this means it also decrypts this data
automatically when retrieved, allowing an SQL injection flaw to retrieve
credit card numbers in clear text. The system should have encrypted the credit card
numbers using a public key, and only allowed back-end applications to
decrypt them with the private key.
Scenario #2: A site simply doesn’t use SSL for all authenticated pages. Attacker simply
monitors network traffic (like an open wireless network), and steals the user’s
session cookie. Attacker then replays this cookie and hijacks the user’s session,
accessing the user’s private data.
Scenario #3: The password database uses unsalted hashes to store everyone’s passwords. A file
upload flaw allows an attacker to retrieve the password file. All of the unsalted
hashes can be exposed with a rainbow table of pre-calculated hashes.
7. Missing Function Level Access Control
Most of the web applications verify function level access rights before making
that functionality accessible to the user. However, if the same access control
checks are not performed on the server, hackers are able to penetrate into the
application without proper authorization.
Defense: The best way to find out if an application has failed to properly restrict
function level access is to verify every application function:
1. Does the UI show navigation to unauthorized functions?
2. Are server side authentication or authorization checks missing?
3. Are server side checks done that solely rely on information provided by the attacker?
8. Cross Site Request Forgery Attacks
A CSRF attack forces an authenticated user (victim) to send a forged HTTP request,
including session cookie, which allows the attacker to force the victim's browser
to generate request such that the vulnerable app perceives as legitimate requests
from the victim
Defense
1. CSRF can be avoided by using unique token
2. CAPTCHA can be used to revalidate user.
3. Only except Post request for the execution of business logic
9. Using Components with Known Vulnerabilities Components
When known vulnerabilities in the code exist, components, such as libraries and
frameworks delivered from the open source community, shouldn’t be used
Defense:
1. Identify all components and the versions that are being used in the webapps
2. Keep all the components such as public databases, project mailing lists etc. up to date.
3. Add security wrappers around components that are vulnerable in nature
10. Unvalidated Redirects and Forwards
Web applications on the internet frequently redirect and forward users to other
pages or external websites. Without validating the credibility hackers can redirect
victims to phishing or malware sites, or use forwards to access unauthorized pages.
Defense:
1. Simply avoid using redirects and forwards.
2. If used, don’t involve user parameters in calculating the destination. This can usually be done.
3. If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user.
Ref: https://www.owasp.org
No comments:
Post a Comment