Hacking Web Application Control Measures

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:
        • %3d =
        • %0a New Line
        • %20 space
    • 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
        • %u2215 /
      • UTF-8: It is a variable-length encoding standard which uses each bytes expressed in hexadecimal and preceded by the % prefix.
        • %c2%a9
        • %e2%89%a0
    • 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.
      • Example:
        • 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…)
        • Hello A125C458D8 
        • Jason 123B684AD9 

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.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *