Websites are hosted on web servers. Web servers are themselves computers running an operating system; connected to the back-end database, running various applications. Any vulnerability in the applications, Database, Operating system or in the network will lead to an attack on the web server. Vulnerability stack of a web server is given below (source: White hat security)
Encoding Schemes (?)
- Web applications employ different encoding schemes for their data to safely handle unusual characters and binary data in the way you intend.
- Types of Encoding Schemes:
- URL Encoding:
- URL encoding is the process of converting URL into valid ASCII format so that data can be safely transported over HTTP.
- URL encoding replaces unusual ASCII characters with “%” followed by the character’s two-digit ASCII code expressed in hexadecimal such as:
%0a New Line
- HTML Encoding:
- An HTML encoding scheme is used to represent unusual characters so that they can be safely combined within an HTML document.
- It defines several HTML entities to represent particularly usual characters such as:
- Unicode Encoding:
- 16 bit Unicode Encoding: It replaces unusual Unicode characters with “%u” followed by the character’s Unicode code point expressed in hexadecimal
- UTF-8: It is a variable-length encoding standard which uses each bytes expressed in hexadecimal and preceded by the % prefix.
- Base64 Encoding:
- Base64 encoding scheme represents any binary data using only printable ASCII characters.
- Usually it is used for encoding email attachments for safe transmission over SMTP and also used for encoding user credentials.
cake 01100011 01100001 01101011 01100101
- Base64 Encoding: 011000 110110 000101 101011 011001 010000 000000 000000 (I don’t know what is this)
- Hex Encoding:
- HTML encoding scheme uses hex value of every character to represent a collection of characters for transmitting binary data.
- Example: (I don’t know, what kind of example is this…)
How to Defend Against SQL Injection Attacks
- Limit the length of user input
- Use custom error messages
- Monitor DB traffic using an IDS, WAF
- Disable commands like xp_cmdshell
- Isolate database server and web server
- Always use method attribute set to POST and low privileged account for DB connection
- Run database service account with minimal rights
- Move extended stored procedures to an isolated server
- Use typesafe variables or functions such as IsNumberic() to encure typesafety
- Validate and sanitize user inputs passed to the database
How to Defend Against Command Injection Flaws
- Perform input validation
- Escape dangerous characters
- Use language-specific libraries that avoid problems due to shell commands
- Perform input and output encoding
- Use a safe API which avoids the use of the interpreter entirely
- Structure requests so that all supplied parameters are treated as data, rather than potentially executable content
- Use parameterized SQL queries
- Use modular shell disassociation from kernel
How to Defend Against XSS Attacks
- Validate all headers, cookies, query strings, form fields, and hidden fields (i.e., all parameters) against a rigorous specification.
- Use a web application firewall to block the execution of malicious script.
- Encode input and output and filter Meta characters in the input.
- Filtering script output can also defeat XSS vulnerabilities by preventing them from being transmitted to users.
- Use testing tools extensively during the design phase to eliminate such XSS holes in the application before it goes into use.
- Convert all non-alphanumeric characters to HTML character entities before displaying the user input in search engines and forums.
- Do not always trust websites that use HTTPS when it comes to XSS.
- Develop some standard or signing scripts with private and public keys that actually check to ascertain that the script introduced is really authenticated.
How to Defend Against DoS Attack
- Configure the firewall to deny external Internet Control Message Protocol (ICMP) traffic access.
- Secure the remote administration and connectivity testing.
- Prevent use of unnecessary functions such as gets, strcpy, and return addresses form overwritten etc.
- Prevent the sensitive information from overwriting.
- Perform thorough input validation.
- Data processed by the attacker should be stopped from being executed.
How to Defend Against Web Services Attack (?)
- Configure WSDL Access Control Permissions to grant or deny access to any type of WSDL-based SOAP messages.
- Use document-centric authentication credentials that use SAML.
- Use multiple security credentials such as X.509 Cert, SAML assertions and WS-Security.
- Deploy web services – capable firewalls capable of SOAP and ISAPI level filtering.
- Configure firewalls/IDS systems for a web services anomaly and signature detection.
- Configure firewalls/IDS systems to filter improper SOAP and XML syntax.
- Implement centralized inline requests and responses schema validation.
- Block external references and use prefetched content when dereferencing URLs.
- Maintain and update a secure repository of XML schemas.
Guidelines for Secure CAPTCHA Implementation (?)
- The client should not have direct access to the CAPTCHA solution.
- No CAPTCHA reuse and present randomly distorted CAPTCHA image of text to the user.
- Use a well-established CAPTCHA implementation such as reCAPTCHA instead of creating your own CAPTCHA script and allow users to choose an audio or sound CAPTCHA.
- Warp individual letters so that OCR engines cannot recognize them.
- Include random letters in the security code to avoid dictionary attacks.
- Encrypt all communications between the website and the CAPTCHA system.
- Use multiple fonts inside a CAPTCHA to increase the complexity of OCR engines to solve the CAPTCHA.
Web Application Attack Countermeasures (?)
- Unvalidated Redirects and Forwards:
- Avoid using redirects and forwards.
- If destination parameters cannot be avoided, ensure that the supplied value is valid, and authorized for the user.
- Cross-Site Request Forgery:
- Logoff immediately after using a web application and clear the history.
- Do not allow your browser and websites to save login details.
- Check the HTTP Referrer header and when processing a POST, ignore URL parameters.
- Broken Authentication and Session Management:
- Use SSL for all authenticated parts of the application.
- Verify whether all the users’ identities and credentials are stored in a hashed form.
- Never submit session data as part of a GET, POST.
- Insecure Cryptographic Storage:
- Do not create or use weak cryptographic algorithms.
- Generate encryption keys offline and store them securely.
- Ensure that encrypted data stored on disk is not easy to decrypt.
- Insufficient Transport Layer Protection:
- Non-SSL requests to web pages should be redirected to the SSL page.
- Set the ‘secure’ flag on all sensitive cookies.
- Configure SSL provider to support only strong algorithms.
- Ensure the certificate is valid, not expired, and matched all domains used by the site.
- Backend and other connections should also use SSL or other encryption technologies.
- Directory Traversal:
- Define access rights to the protected areas of the website:
- Apply checks/hot fixes that prevent the exploitation of the vulnerability such as Unicode to affect the directory traversal.
- Web servers should be updated with security patches in a timely manner.
- Cookie/Session Poisoning:
- Do not store plain text or weakly encrypted password in a cookie.
- Implement cookie’s timeout.
- Cookie’s authentication credentials should be associated with an IP address.
- Make logout functions available.
- Security Misconfiguration:
- Configure all security mechanisms and turn off all unused services.
- Setup roles, permissions, and accounts and disable all default accounts or change their default passwords.
- Scan for latest security vulnerabilities and apply the latest security patches.
- LDAP Injection Attacks:
- Perform type, pattern, and domain value validation on all input data.
- Make LDAP filter as specific as possible.
- Validate and restrict the amount of data returned to the user.
- Implement tight access control on the data in the LDAP directory.
- Perform dynamic testing and source code analysis.
- File Injection Attack:
- Strongly validate user input.
- Consider implementing a chroot jail.
Usually used to prevent the possibility of programs being overridden and used to access unauthorized files. For example, many FTP servers run in a chroot jail environment to prevent attackers who discover new server vulnerabilities from being able to download password files or other sensitive files on the system.
- PHP: Disable allow_url_fopen and allow_url_include in php.ini.
- PHP: Disable register_globals and use E_STRICT to find uninitialized variables.
- PHP: Ensure that all file and streams functions (stream_*) are carefully vetted.