Common types of Web application attacks.
Source : ibm.com/software/rational/offerings/testing/webapplicationsecurityDescription Common causes Preventive measures Impersonation Typing a different user’s credentials or changing a cookie or parameter to impersonate a user or pretend that the cookie originates from a different server - Using communications based authentication to allow access to any user’s data
- Using unencrypted credentials that can be captured and reused
- Storing credentials in cookies or parameters
- Using unproven authentication methods or authentication from the wrong trust domain
- Not permitting client software to authenticate the host
Use stringent authentication and protection for credential information using:
- Operating system (OS)-supplied frameworks
- Encrypted tokens such as session cookies
- Digital signatures
Tampering Changing or deleting a resource without authorization (e.g., defacing a Web site, altering data in transit) - Trusting data sources without validation
- Sanitizing input to prevent execution of unwanted code
- Running with escalated privileges
- Leaving sensitive data unencrypted
- Use OS security to lock down files, directories and other resources
- Validate your data
- Hash and sign data in transit (by using SSL or IPsec, for example)
Repudiation Attempting to destroy, hide or alter evidence that an action occurred (e.g., deleting logs, impersonating a user to request changes) - Using a weak or missing authorization and authentication process
- Logging improperly
- Allowing sensitive information on unsecured communication channels
- Use stringent authenti-cation, transaction logs and digital signatures
- Audit
Information disclosure Revealing personally identifiable information (PII) such as passwords and credit card data, plus information about the application source and/or its host machines - Allowing an authenticated user access to other users’ data
- Allowing sensitive information on unsecured communication channels
- Selecting poor encryption algorithms and keys
- Store PII on a session (transitory) rather than permanent basis
- Use hashing and encryption for sensitive data whenever possible
- Match user data to user authentication
Denial of service (DoS) - Flooding—sending many messages or simultaneous requests to overwhelm a server
- Lockout—sending a surge of requests
to force a slow server response by consuming resources or causing the appli-cation to restart
- Placing too many applications on a single server or placing conflicting applications on the same server
- Neglecting to conduct comprehensive unit testing
- Filter packets using
a firewall - Use a load balancer to control the number of requests from a single source
- Use asynchronous protocols to handle processing-intensive requests and error recovery
Elevation of privilege Exceeding normal access privileges to gain administrative rights or access to confidential files - Running Web server processes as “root” or “administrator”
- Using coding errors to allow buffer overflows and elevate application into a debug state
- Use fewest-privileges context whenever possible
- Use type-safe languages and compiler options
to prevent or control buffer overflows
- Using communications based authentication to allow access to any user’s data
- Using unencrypted credentials that can be captured and reused
- Storing credentials in cookies or parameters
- Using unproven authentication methods or authentication from the wrong trust domain
- Not permitting client software to authenticate the host
Use stringent authentication and protection for credential information using:
- Operating system (OS)-supplied frameworks
- Encrypted tokens such as session cookies
- Digital signatures
- Trusting data sources without validation
- Sanitizing input to prevent execution of unwanted code
- Running with escalated privileges
- Leaving sensitive data unencrypted
- Use OS security to lock down files, directories and other resources
- Validate your data
- Hash and sign data in transit (by using SSL or IPsec, for example)
- Using a weak or missing authorization and authentication process
- Logging improperly
- Allowing sensitive information on unsecured communication channels
- Use stringent authenti-cation, transaction logs and digital signatures
- Audit
- Allowing an authenticated user access to other users’ data
- Allowing sensitive information on unsecured communication channels
- Selecting poor encryption algorithms and keys
- Store PII on a session (transitory) rather than permanent basis
- Use hashing and encryption for sensitive data whenever possible
- Match user data to user authentication
- Flooding—sending many messages or simultaneous requests to overwhelm a server
- Lockout—sending a surge of requests
to force a slow server response by consuming resources or causing the appli-cation to restart
- Placing too many applications on a single server or placing conflicting applications on the same server
- Neglecting to conduct comprehensive unit testing
- Filter packets using
a firewall - Use a load balancer to control the number of requests from a single source
- Use asynchronous protocols to handle processing-intensive requests and error recovery
- Running Web server processes as “root” or “administrator”
- Using coding errors to allow buffer overflows and elevate application into a debug state
- Use fewest-privileges context whenever possible
- Use type-safe languages and compiler options
to prevent or control buffer overflows
0 comments:
Post a Comment