12.5 Countermeasures

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:
        • & &
        • &lt; <
        • &gt; >
    • 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 (不懂，這是什麼東西)
    • Hex Encoding:
      • HTML encoding scheme uses hex value of every character to represent a collection of characters for transmitting binary data.
      • Example: (不懂，這是什麼例子...)
        • 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.

      通常是用來阻止程式被推翻、並用來存取未經授權檔案的可能性。例如，很多 FTP 伺服器在 chroot jail 環境中執行，以便用來防止發現新伺服器弱點的攻擊者有能力下載密碼檔或者其他系統中的敏感檔案。

    • 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.

How to Defend Against Web Application Attacks

results matching ""

    No results matching ""