Sunday, November 18, 2012

Security: OWASP Cheat Sheets summary

REST Security Cheat Sheet

  • It is common for REST services to allow multiple response types (e.g. application/xml or application/json, and the client specifies the preferred order of response types by the Accept header in the request. Do NOT simply copy the Accept header to the Content-type header of the response. Reject the request (ideally with a 406 Not Acceptable response) if the Accept header does not specifically contain one of the allowable types.
  • It is important for the service to properly restrict the allowable verbs(GET, POST etc) such that only the allowed verbs will work, all others return a proper response code (for example, a 403 Forbidden). This is because someone can use http HEAD with that URL and we won't be able to check.
  • Authentication for a REST-based service should not take place by passing the user ID and password in path elements of the URL. URL's are commonly cached

Business Requirements

  • Business Model

  • Data Essentials

  • End-Users

  • Partners

  • Administrators

  • Regulations

Infrastructure Requirements
  • Network
  • Systems
  • Infrastructure Monitoring
  • Virtualization and Externalization

Application Requirements
  • Environment
  • Data Processing
  • Access
  • Application Monitoring
  • Application Design
Security Program Requirements
  • Operations
         - identifying and addressing vulnerabilities
  • Change Management
  • Software Development
  • Corporate
            - employee
            - governance requirements

Web Service Security Cheat Sheet

XML Denial of Service Protection
XML Denial of Service is probably the most serious attack against web services. So the web service must provide the following validation:
  • Rule - Validation against recursive payloads
  • Rule - Validation against oversized payloads
  • Rule - Protection against XML entity expansion
  • Rule - Validating against overlong element names. If you are working with SOAP-based Web Services, the element names are those SOAP Actions.
Input Validation Cheat Sheet

Some white list validators have also been predefined in various open source packages that you can leverage. Two packages that provide this are:
It is recommended that you use ESAPI to assist with your input validation needs, rather than writing your own validation routines. The OWASP Enterprise Security API (ESAPI) project has predefined validators defined in the org.owasp.esapi.Validator interface and implemented in the DefaultValidator reference implementation. These include:
  • getValidDate()
  • getValidSafeHTML()
  • getValidInput()
  • getValidNumber()
  • getValidFileName()
  • getValidRedirectLocation()

Cryptography

Relevant COBIT Topics
DS5.18 – Cryptographic key management

Cryptographic systems can provide one or more of the following four services:
  • Authentication:SSL Certs
  • Non-Repudiation:digitally signing
  • Confidentiality
  • Integrity:Cryptographic hashes


Cryptographic Algorithms

  • Asymmetric (also Public/Private Key Cryptography)

PGP and SSL are prime examples of a systems implementing asymmetric cryptography, using the RSA(asym cipher) or other algorithms. Common Asymmetric signature scheme is DSA ( Digital Signature Algorithm)
  • Symmetric

. Common examples of symmetric algorithms are DES, 3DES and AES. DES should no longer be used.

  • Hashes

Hash functions take some data (and possibly a key or password) and generate a unique hash or checksum. MD5 and SHA-1 are common hashing algorithms used today. These algorithms are considered weak (see below) and are likely to be replaced after a process similar to the AES selection. New implementations should consider using SHA-256 instead of these weaker algorithms.
Message Authentication Codes ( MAC), uses keys and are used as hash functional as well.

Use good sources of randomness. JCE as one.


Key Exchange Algorithms

Lastly, we have key exchange algorithms (such as Diffie-Hellman for SSL). These allow use to safely exchange encryption keys with an unknown party. 

Stream Ciphers
Stream ciphers, such as RC4, are vulnerable due to a property of stream ciphers. If you use the same key to “protect” two different documents, the keystream drops out when you XOR the two documents together, leaving the plaintexts XOR’d together. The two plain text documents can be recovered using frequency analysis. 











Specific algorithms to avoid:

MD5 has recently been found less secure than previously thought.
SHA-0 has been conclusively broken.
SHA-1 has been reduced in strength and we encourage a migration to SHA-256, which implements a larger key size

DES was once the standard crypto algorithm for encryption; a normal desktop machine can now break it. AES is the current preferred symmetric algorithm.



Recommendations

Symmetric:
·       Key sizes of 128 bits (standard for SSL) are sufficient for most applications
·       Consider 168 or 256 bits for secure systems such as large financial transactions
Asymmetric:
·       Key sizes of 1280 bits are sufficient for most personal applications
·       1536 bits should be acceptable today for most secure applications
·       2048 bits should be considered for highly protected applications.
Hashes:
·       Hash sizes of 128 bits (standard for SSL) are sufficient for most applications
·       Consider 168 or 256 bits for secure systems, as many hash functions are currently being revised (see above).

  • SSL 2.0 should never be used.
  • multiple domain certificates or enhanced wildcard certificates can be used to provide a listing of multiple names in a certificate.
  • TLS has renegotiation vulnerability which most browsers have corrected.
  • NIST SP 800-52 recommends to use TLS 1.0 with RSA or DSA, with ephemeral Diffie Hellman, 3DES or AES and SHA1 (or SHA256) for integrity protection. MD5 and RC4 are disallowed.




Cryptographic Storage Cheat Sheet

  • 2.3.1 Rule - Only store sensitive data that you need
  • 2.3.2 Rule - Only use strong cryptographic algorithms
    Symmetric Key
             Currently, there exist three FIPS-approved symmetric key algorithms for encryption: Advanced Encryption Standard    (AES), Triple-DES, and Skipjack. AES is the FIPS-Approved symmetric encryption algorithm of choice.

             Asymmetric Key
FIPS 186-3 Digital Signature Standard (DSS) (DSA, RSA, and ECDSA algorithms)
On June 10, 2009, NIST announced the adoption of FIPS 186-3, Digital Signature Standard (DSS), which is a revision of FIPS 186-2. The FIPS specifies three techniques for the generation and verification of digital signatures:

Digital Signature Algorithm (DSA), RSA (as specified in ANSI X9.31 (RSA)), and Elliptic Curve DSA (ECDSA; as specified in ANSI X9.62).

Secure Hash Standard (SHS)
(SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 algorithms)
The Secure Hash Algorithms (SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512) are specified in FIPS 180-3 dated October 2008, Secure Hash Standard (SHS).


Random Number Generators (RNG)
The algorithms for generating approved random numbers are referenced in FIPS 140-2 Annex C.


Message Authentication (MAC)
Block Cipher-based MAC Algorithm (CMAC)
The CMAC algorithm is specified in Special Publication 800-38B dated May 2005, Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication. CMAC can be considered a mode of operation of the block cipher because it is based on an approved symmetric key block cipher, such as the Advanced Encryption Standard (AES) algorithm currently specified in Federal Information Processing Standard (FIPS) Pub. 197. CMAC is also an approved mode of the Triple Data Encryption Algorithm (TDEA).

Keyed-Hash Message Authentication Code (HMAC)
The Keyed-Hash Message Authentication Code (HMAC) is specified in FIPS 198 dated March 6, 2002, Keyed-Hash Message Authentication Code (HMAC). This algorithm utilizes the Secure Hash Algorithms as an underlying primitive.


  • 2.3.2.1 Rule - Ensure that random numbers are cryptographically strong
Ensure that all random numbers, random file names, random GUIDs, and random strings are generated in a cryptographically strong fashion. Also ensure that random algorithms are seeded with sufficient entropy.

  • 2.3.2.2 Rule - Only use widely accepted implementations of cryptographic algorithms
  • 2.3.2.3 Rule - Prefer authenticated encryption modes
Use cryptographic cipher modes that offer both confidentiality and authenticity. Recommended modes include counter with CBC-MAC (CCM) mode and Galois/counter mode (GCM). These authenticated encryption (AE) modes resist padding oracle attacks which can be used in many cases to recover plaintext from ciphertext without knowledge of the encryption key.

  • 2.3.3 Rule - Store the hashed and salted value of passwords
  • 2.3.4 Rule - Ensure that the cryptographic protection remains secure even if access controls fail
  • 2.3.5 Rule - Ensure that any secret key is protected from unauthorized access
  • 2.3.5.1 Rule - Define a key lifecycle
  • 2.3.5.2 Rule - Store unencrypted keys away from the encrypted data
  • 2.3.5.3 Rule - Use independent keys when multiple keys are required
  • 2.3.5.4 Rule - Protect keys in a key vault
  • 2.3.5.5 Rule - Document concrete procedures for managing keys through the lifecycle
  • 2.3.5.6 Rule - Build support for changing keys periodically
  • 2.3.5.7 Rule - Document concrete procedures to handle a key compromise
  • 2.3.5.8 Rule - Rekey data at least every one to three years
  • 2.3.6 Rule - Follow applicable regulations on use of cryptography
  • 2.3.6.1 Rule - Under PCI DSS requirement 3, you must protect cardholder data
PCI DSS requirement 3 covers secure storage of credit card data. This requirement covers several aspects of secure storage including the data you must never store but we are covering Cryptographic Storage which is covered in requirements 3.4, 3.5 and 3.6 as you can see below:
  • 3.4 Render PAN (Primary Account Number), at minimum, unreadable anywhere it is stored
  • 3.5 Protect any keys used to secure cardholder data against disclosure and misuse
  • 3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data
Requirement 3.6 mandates that key management processes within a PCI compliant company cover 8 specific key lifecycle steps:
  • 3.6.1 Generation of strong cryptographic keys

  • 3.6.2 Secure cryptographic key distribution
The method used to distribute keys must be secure to prevent the theft of keys in transit. The use of a protocol such as Diffie Hellman can help secure the distribution of keys, the use of secure transport such as SSLv3, TLS and SSHv2 can also secure the keys in transit.
  • 3.6.3 Secure cryptographic key storage
The secure storage of encryption keys including KEK's has been touched on in our description of requirement 3.5 (see above).
  • 3.6.4 Periodic cryptographic key changes
The PCI DSS standard mandates that keys used for encryption must be rotated at least annually.
  • 3.6.5 Retirement or replacement of keys as deemed necessary when the integrity of the key has been weakened or keys are suspected of being compromised
  • 3.6.6 Split knowledge and establishment of dual control of cryptographic keys
  • 3.6.7 Prevention of unauthorized substitution of cryptographic keys
  • 3.6.8 Requirement for cryptographic key custodians to sign a form stating that they understand and accept their key-custodian responsibilities

SSL/TLS

TLS version 1.0 and SSL 3.0 are very similar. SSL 3.1 is identical to TLS 1.0

Handshake process
  • TLS begins by client initiating the handshakre protocol with hello message that includes protocol version, session id, cipher suite, compression method and a random number.
  • server responds with hello msg that includes protocol version, session id, cipher suite, compression method and a random number.
  • server then sends it cert and msg indicating it finished with hello msg.
  • client responds with a key exchange msg. for instance in the case of TLS_RSA_WITH_RC4_CBC_MD5, the client generates a 48 byte premaster secret and encrypts it with the servers RSA public key.
    • 48 byte includes 2 bytes for client version and 46 random bytes 
  • server decrypts the key exchange msg and verifies first two bytes are same as earlier client version.
  • Now both client and server use random numbers exchanged and pre master secret with a pseudo random function (PRF) to generate master secret. 
    • master secret is 48 bytes long. It has 3 128 bit keys; one for keyed MD5 (MAC), one for symmetric(RC4) and one as initialization vector for symmetric algorithm.
  •  client/server send handshake finished to each other.
  • now session keys based on master secret are used for remainder of TLS session.

TLS benefits
  • integrity guarantees
  • replay prevention
Online Certificate status protocol (OCSP) responder to check for certificate revocation status.

Crypto Module
  • components that implement crypto algos
  • components that call and manage crypto functions
  • physical container around the above two.

  • For FIPS 140-2:
    • SSL must be disabled and TLS must be used.


  • Set the "secure" flag for the cookie to avoid sending in http mode ( versus https)
  • Strict transport security will provide a server side control to instruct browsers to use https only.


Database Encryption

Transparent Data Encryption is a new feature in SQL Server 2008 which implements database-level encryption complementing the row-level encryption which is currently available in SQL Server 2005. This protects database access, either directly or by restoring a database backup on another SQL Server instance.


  • Setting up encryption on the server. To do that, we create the database master key on the master database


USE master
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'mY_P@$$w0rd'


  • Then, we create the server-based certificate which will be used to encrypt the database


CREATE CERTIFICATE NorthwindCert
WITH SUBJECT = 'My DEK Certificate for Northwind database'


  • We will then set the encryption for the Northwind database by creating a database encryption key and password using the certificate we just created.


USE Northwind
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE NorthwindCert
GO

  • The encryption algorithm choice is yours, since a few different options exist.  For guidance on selecting an encryption algorithm on SQL Server, check out this Microsoft TechNet article.  After creating the database encryption key, we'll enable encryption on the database level.


ALTER DATABASE Northwind
SET ENCRYPTION ON

  • Let's backup the encrypted Northwind database this time but using a different filename.


BACKUP DATABASE Northwind
TO DISK = 'C:\Northwind_encrypted.bak'
WITH INIT, STATS = 10

  • The encrypted backup would take a bit longer than the unencrypted backup. If you open the encrypted database backup and search for the string 'A r i a   C r u z' which we searched for earlier, you will no longer find it. 



Session Management

  • Set secure and HttpOnly flags for session cookies. Send CSRF tokens with forms.
  • Throttle requests from a particular user.



Authentication  & Authorization

Relevant COBIT Topics: DS5 – All sections should be reviewed.

  • username and password is suitable for low value systems such as blogs and forums, SMS challenge response is suitable for low value e-commerce systems (in 2005), whilst transaction signing is suitable for high value systems such as high value e-commerce
  • HTTP 1.1 Digest authentication uses a challenge response mechanism, which is reasonably safe for low value applications.
  • Certificate revocation with self-issued certificates is almost impossible in extranet environments.
  • Soft certificates (also known as client-side certificate authentication) are a little stronger than passwords, but suffer from the same problems as passwords and any authentication method which automatically processes credentials.
  • Challenge Response: Challenge response tokens work by taking a value (challenge) from the system and processing them in a cryptographically secure fashion to derive a result.
  • Transaction signing is performed by offline challenge response calculators. The user will be presented with various items to enter into the calculator, and it will calculate a response based upon these inputs. This is the strongest form of authentication as the user has to enter the transaction details – any other transaction will fail to produce a suitable response. This type of authentication has strong non-repudiation properties, is robust against man in the middle attacks, cannot be replayed, and is robust against differing transaction limits.
    For the best effect, at least the following should be stirred into the challenge:
    ·       Reference ID
    ·       From account
    ·       Amount of the transaction

  • Use decent one-way hash algorithm, such as AES-128 in digest mode or SHA-256 bit.
  • Check that the app has a delay between the user submitting the credential and a success or failure is reported. A delay of three seconds can make automated brute force attacks almost unfeasible. A progressive delay (3 seconds then 15 then 30 then disconnect) can make casual brute force attacks completely ineffective
  • Event correlation software such as Simple Event Correlator (SEC) can be used to define rules to parse through the logs and generate alerts based on aggregated events. This could also be done by adding a Snort rule for alerting on HTTP Authorization Failed error messages going out from your web server to the user, and SEC can then be used to aggregate and correlate these alerts.
  • Note: Any web site that is mandated or legally required to be accessible must not use CAPTCHA’s. if you can't:
    • You have to provide alternate means of registration etc.
    • deter the use of automated sign ups by using the “no follow” tag. Search engines will ignore hyperlinks and pages with this tag set, immensely devaluing the use of link spamming




Session Management
  • Relevant COBIT Topics
    • PO8 – All sections should be reviewed
    • PO8.4 – Privacy, Intellectual proeprty and data flow
  • The session ID value must provide at least 64 bits of entropy (if a good PRNG is used, this value is estimated to be half the length of the session ID).
  • the “Secure” cookie attribute (see below) must be used to ensure the session ID is only exchanged through an encrypted channel. The usage of an encrypted communication channel also protects the session against some session fixation attacks where the attacker is able to intercept and manipulate the web traffic to inject (or fix) the session ID on the victims web browser [4].
  • Web applications should never switch a given session from HTTP to HTTPS, or viceversa, as this will disclose the session ID in the clear through the network
  • Web applications should not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host (or even domain - see the “domain” cookie attribute), as the request of any web object over an unencrypted channel might disclose the session ID
  • Web applications should make use of “HTTP Strict Transport Security (HSTS)” (previously called STS) to enforce HTTPS connections.
  • The “Secure” cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection.
  • Forcing the web application to only use HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against session ID disclosure if the “Secure” cookie has not been set - the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear.
  • The “HttpOnly” cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks.
  • The “Domain” cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The “Path” cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie.
    • It is recommended to use a narrow or restricted scope for these two attributes. In this way, the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID.
  • it is recommended not to mix web applications of different security levels on the same domain. Vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permissive “Domain” attribute (such as “example.com”) which is a technique that can be used in session fixation attacks
  • Although the “Path” attribute allows the isolation of session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host. Other methods can be used by these applications to access the session IDs, such as the “document.cookie” object. Also, any web application can set cookies for any path on that host.
  • Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain.
  •  If a cookie presents the “Max-Age” (that has preference over “Expires”) or “Expires” attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based until the expiration time. Typically, session management capabilities to track users after authentication make use of non-persistent cookies. 
  •  The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session.
    •  The session ID regeneration is mandatory to prevent session fixation attacks [3], where an attacker sets the session ID on the victims user web browser instead of gathering the victims session ID
  • All sessions should implement an absolute timeout, regardless of session activity. This timeout defines the maximum amount of time a session can be active, closing and invalidating the session upon the defined absolute period 
  •  Web applications should focus on detecting anomalies associated to the session ID, such as its manipulation. The OWASP AppSensor Project [7] provides a framework and methodology to implement built-in intrusion detection capabilities within web applications focused on the detection of anomalies and unexpected behaviors, in the form of detection points and response actions.
  • bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate
    • A skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots), by using the same outbound web proxy (very common in corporate environments), or by modifying his User-Agent to look exactly as the victim users does.
    • Can also tie the session to a particular browser by using a hash of the server-side IP address (REMOTE_ADDR) and if the header exists, PROXY_FORWARDED_FOR. Note that you shouldn’t use the client-forgeable headers, but take a hash of them. If the new hash doesn’t match the previous hash, then there is a high likelihood of session replay.
  •  In situations where the web application source code is not available or cannot be modified or requires complete redesign, or to complement the web application defenses, and with the goal of keeping the web application as secure as possible, it is recommended to use external protections such as Web Application Firewalls (WAFs) that can mitigate the session management threats
  •  The open-source ModSecurity WAF, plus the OWASP Core Rule Set [6], provide capabilities to detect and apply security cookie attributes, countermeasures against session fixation attacks, and session tracking features to enforce sticky sessions.
  •  Form data should not contain hidden fields – if it is hidden, it probably needs to be protected and only available on the server side. However, hidden fields can (and should) be used for sequence protection and to prevent brute force pharming attacks. 

  • storing all state within each request(in contrast to storing in session), leads to extensive use of hidden fields and extra database queries to avoid server-side session management, and is vulnerable to replay and request forgery attacks, as well as producing complex code.
  • Some frameworks use shared areas of the web server’s disk to store session data. In particular, PHP uses /tmp on Unix and c:\windows\temp on Windows by default. These areas provide no protection for session data, and may lead to compromise.
  • Page and Form Tokens
    • Page specific tokens or "nonces" may be used in conjunction with session specific tokens to provide a measure of authenticity when dealing with client requests.
    • Page tokens are often stored in cookies or query strings and should be completely random. It is possible to avoid sending session token information to the client entirely through the use of page tokens, by creating a mapping  
  • If a session handler issues tokens which are predictable, an attacker does not need to capture session variables from the remote users – they can simply guess.
  • Consider using "booby trapped" session tokens that will detect a brute force attack.Then: 
    • Go slow or ban the originating IP address (which can be troublesome as more and more ISPs are using transparent caches to reduce their costs. Because of this: always check the "proxy_via" header)
    • Apache web server modules, such as mod_dosevasive and mod_security, that could be used for this kind of protection. Although mod_dosevasive is used to lessen the effect of DoS attacks, it could be rewritten for other purposes as well 
  • Associate the session ID, IP address, and other attributes from the user’s headers in a hash. If the hash changes, and more than one of the details has changed, it is likely that a session fixation attack has occurred.
  • Use Brutus to check if you can brute force a session and resume it. If yes, then session id requires greater entropy.
Data Validation


 Data Validation Strategies
There are four strategies for validating data, and they should be used in this order:
  • Accept known good
  • Reject known bad. If you don't expect to see characters such as %3f or JavaScript or similar, reject strings containing them:
  • Sanitize: Eliminate or translate characters (such as to HTML entities or to remove quotes) in an effort to make the input "safe":
  • No validation: not a strategy at all :-) 
Tips:
  • Code containing hidden fields should be rejected during code reviews.
  • Some strings may be received in encoded form. It is essential to send the correct locale to the user so that the web server and application server can provide a single level of canoncalization prior to the first use.
  • Do not use getReader() or getInputStream() as these input methods do not decode encoded strings. If you need to use these constructs, you must decanoncalize data by hand.
Interpreter Injection
  • Relevant COBIT Topics
    • DS11 – Manage Data – All sections should be reviewed
    • DS11.9 – Data processing integrity
    • DS11.20 – Continued integrity of stored data

XSS ( all variations)
SQL Injection
LDAP Injection

HTTP Response Splitting
This attack, uses a weakness in the HTTP protocol definition to inject hostile data into the user’s browser. Klein describes the following classes of attacks:
·       Cross-Site Scripting (XSS)
·       Web Cache Poisoning (defacement)
·       Cross User attacks (single user, single page, temporary defacement)
·       Hijacking pages
·       Browser cache poisoning
In HTTP, the headers and body are separated by a double carriage return line feed sequence. If the attacker can insert data into a header, such as the location header (used in redirects) or in the cookie, and if the application does not protect against CRLF injection, it is quite likely that the application will be vulnerable to HTTP Response Splitting. The attack injects two responses (thus the name), where the first response is the attacker’s payload, and the second response containing the rest of the user’s actual output, is usually ignored by the web server. 

Code Injection
Java generally does not contain the ability to evaluate dynamic JSPs. However, there are two exceptions to this:
·       Dynamic JSP inclusion (<jsp:include ...>)
·       Using a third party JSP eval taglibs.
·       Portals and other community-based software often require the evaluation of dynamic code for templates and skinning. If the portal software requires dynamic includes and dynamic code execution, there is a risk of Java or JSP code injection.

To combat this, the primary defenses are to
·       Always prefer static include ( <% include ... %> )
·       Not allow the inclusion of files outside of the server by using Java 2 Security policies
·       Establish firewall rules to prevent outbound Internet connectivity
·       Ensure that code does not interpret user data without prior validation.

Generally, dynamic inclusion and dynamic code evaluation should be frowned upon.







Posted by at No comments:
Subscribe to: Posts (Atom)