HTTP response and other metadata

Distributed Abnormally Long request:-

HTTP flood attacker volumetric attack, allien using a botnet “Zombie army”. It is bring down the targeted site or server. It is also a type of DDOS attack.

HTTP flood attacks are very difficult to differentiate from valid traffic because they use standard URL requests. This makes them one of the most advanced non-vulnerability security challenges facing servers and applications today. Traditional rate-based detection is ineffective in detecting HTTP flood attacks, since traffic volume in HTTP floods is often under detection thresholds.

The most highly-effective mitigation on a combination of traffic profiling methods, including identifying IP reputation, keeping track abnormal activity and employing progressive security challenges (e.g., asking to parse JavaScript).

Distributed Illegal HTTP version:-

Attacker use illegal version like .9. WAF trigger the alert of HTTP illegal HTTP version.

Distributed Too many headers per response:-

If an application server receives too many headers there are more headers than are defined as the max. according to the config.

Prevent:-

The max. number of headers can be increased using the ‘Maximum Headers’ property associated with the HTTP transport or the ‘limitNumHeaders’ property on a transport channel.

Variation of HTTP Parameter:-

WAF detect HTTP parameter pollution attack and customer can choose to either alert or block session that attempt to pass multiple HTTP parameter like null value.

Null character is harmful may be it’s deploy the null injection.

Prevent:-

WAF policy-“null character in parameter name” that is currently set to alert customer should review that alerts generate  the policy and check for any false positive.

See the below Null injection blog

Ovely permissive CORS

Origin header is sent by the browser in a CORS request and indicates that origin request. It may be spoofed outside the browser, so need to check that application-level protocols for protect sensitive data.

Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response.

Insecure configurations as for example using '*' wildcard as value of the Access-Control-Allow-Origin header means all domains are allowed. Other insecure example is when the server returns back the Origin header without any additional checks, what can lead to access of sensitive data. This configuration is very insecure, and is not acceptable, except in case of a public API that is intended to be accessible by everyone.

add_header Access-Control-Allow-Origin $cors_header;

add_header Access-Control-Allow-Credentials true;

Query Parameter SSL

URL contain a sensitive query parameter and stored in the browser history. Web application may be configured log the URL of all request. So, result is sensitive parameter is saved in the log.

Fix:

The solution to this problem requires two steps:

· If necessary then pass sensitive data. Once a user is authenticated with a session ID limited lifetime.

· Use non-persistent, session level cookies to hold session IDs and other private data.

The advantage of using session level cookies to carry this information:

· They are not stored in the browsers history or on the disk

· They are usually not stored in server logs

· They are not passed to embedded resources such as images or javascript libraries

. They only apply to the domain and path for which they were issued

Insecure HTTP Methods Enabled

Attacker sends a request of type "OPTIONS" to the Web server of your application to determine what HTTP methods are supported by the server. Allow: HEAD, GET, PUT, POST, DELETE, TRACE, OPTIONS

The header Allow includes a list of supported HTTP methods.

Application is insecure if Allow header contains methods such as DELETE or PUT.

Web Application Source Code Disclosure Pattern Found

It is possible to retrieve the source code from server side script and also may possible to expose the business logic or sensitive information such as username and password.

Possible Causes

· Patches for 3rd. party products were not installed

· Temporary files were left in production environment

· Debugging information was left by the programmer in web pages

Application source code should not be accessible to web users, as it may contain sensitive application information and back-end logic.

It can give an attacker useful guidance for future exploitation. Leakage of sensitive information may carry various levels of risk and should be limited whenever possible.

Recommendation

There are many ways to revealing application source code. To ensure that your application does not allow web users access to source code. [1] Check that all system patches related to source code disclosure are installed. [2] Check that no application source code is left in HTML comments. [3] Check that all source code files are removed from the production environment

Security terms Salt, Nonce, Rainbow

Salt

A new salt (form of encryption) is randomly generated for each password. Setting a salt and a password are concatenated and processed with a cryptographic hash function, and the resulting output (but not the original password) is stored with the salt in a database.

Nonce

Nonce is an arbitrary number used only once in a cryptographic communication. It is a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks.

Rainbow

A rainbow table is a precomputed table. This table use for reversing cryptographic hash function, usually for cracking password hashes. Tables using for recover a plaintext password up to a certain length consisting of a limited set of characters. It take less computer processing time and more storage than a brute-force attack which calculates a hash on every attempt, but more processing time and less storage than a simple lookup table with one entry per hash.

Authentication and Authorization

· Authentication is the process of verifying who you are. When you log on to a PC with a user name and password you are authenticating.

· Authorization is after verifying that you have access to something. Gaining access to a resource because the permissions configured on it allow you access is authorization.

Authentication can be done using the following methods:

• Local Code42 platform directory
• LDAP
• Single Sign-On (SSO)
• RADIUS

Authorization can be done using the following methods:

· Local Code42 platform directory

• LDAP

Symmetric & Asymmetric Encryption

Symmetric Encryption

Symmetric encryption is the best-known technique. Use a secret key, which can be a number, word, or string of random letters, is applied on a message to change the content in a particular way. It is very simple as shifting each letter by a number of places in the alphabet. Both sender and recipient know the secret key, Secret key can encrypt and decrypt all messages.

Asymmetric Encryption

When secret keys is exchanging over the Internet might be going the wrong hands. After kept the secret key anyone decrypt the message. Solution is asymmetric encryption, in which there are two related keys--a key pair. A public key is easily available to anyone who want to send a message. A second, private key is kept secret, so that only you know it.

Encrypt message by using the public key can only be decrypt by applying the same algorithm, but by using the matching private key. If message encrypt by using the private key can only be decrypt by using the matching public key.

Potential File Upload or File Upload

User want facility to upload the file. An attacker take the privilege of this facility to upload the malicious file. It have potential to get malware attack or malicious code. Attacker is aim to execute the malicious code in website. This vulnerability is high severity level.

Attacking in a website through the upload file which contain malicious code it may create some issue:-

· System takeover could happen entirely

· Overloading of a database or a file system could occur

· Back-end systems could even become attacked by such malicious code

· Attacks against clients are also possible

· Simple defacement could be the result as well

· In fact, the effect and its hazardous aspects fundamentally vary according to the application’s reaction towards the file and the place where it stores the file essentially

There are two ways to attack file upload.

1. It involve to type of upload file. The file name is already exit it overwrite the existing file. It is generated some metadata like, path, file name which is provided by HTTP encoding. Malicious data may be overwrite the critical file or bad location. For ex, Attacker upload a file on root folder with the name of…/…//index.php.

2. Attacker can be attacked by malicious file upload involves the content of the uploaded file. The uploaded file could contain malicious code in the form of an exploit, virus, Trojan or malware, which could be used to gain control of the Web server. For example, it is possible to hide PHP code inside an image file and still have it appear to be an image. When the image is opened, it also executes the code hidden in the file.

Attacks on application platform

· Upload .jsp file into web tree - jsp code executed as the web user

· Upload .gif file to be resized - image library flaw exploited

· Upload huge files - file space denial of service

· Upload file using malicious path or name - overwrite a critical file

· Upload file containing personal data - other users access it

· Upload file containing "tags" - tags get executed as part of being "included" in a web page

· Upload .rar file to be scanned by antivirus - command executed on a server running the vulnerable antivirus software

Attacks on other systems

· Upload .exe file into web tree - victims download trojaned executable

· Upload virus infected file - victims' machines infected

· Upload .html file containing script - victim experiences Cross site scripting (XSS).

· Upload .jpg file containing a Flash object - victim experiences Cross-site Content Hijacking.

Solution

Create a white list for accepting MIMIE types. NEVER use a blacklist technique.

Can’t access though the Internet.

Define a .htaccess file that will only allow access to files with allowed extensions.

Do not place the .htaccess file in the same directory where the uploaded files will be stored.

The application should use a whitelist of allowed file types. This list determines the types of files that can be uploaded, and rejects all files that do not match approved types.

The application should use client- or server-side input validation to ensure evasion techniques have not been used to bypass the whitelist filter.

The application should set a maximum length for the file name, and a maximum size for the file itself.

The directory to which files are uploaded should be outside of the website root.

All uploaded files should be scanned by antivirus software before they are opened.

The application should not use the file name supplied by the user. Instead, the uploaded file should be renamed according to a predetermined convention.