WASC
Defining WASC – Going Beyond the Abbreviation
Internet security didn't happen overnight; it took the collective effort of numerous developers to create and redefine protocols that could help them quickly discern, analyze and act on security threats as they occurred.
In this context, the 'Web Security Threat Classification' group joined together to create a number of standards, which are now used as a defining benchmark by security experts from around the world.
The standards and classifications, otherwise known as 'Web Application Security Consortium (WASC)' detail numerous issues that online security professionals turn to in order to create a standard safe heaven where everyone online can feel protected. Unfortunately, unethical users can also look to these classifications as a means of challenges to exploit, which means that both security professionals and enterprising hackers are continually trying to stay one step ahead of each other.
Objectively writing, WASC is not just a standard set of rules or security issues benchmarked for certain people; it is a constantly evolving online movement; a universally defined language that is continuing to grow and change as new technologies, defense systems and applications are developed.
Index - WASC27 Categories
*The following security issues categories individually address nearly all possible classes of online vulnerabilities, threats and security exploits. Please refer to this WASC manual as a reference guide only. – For more immediate and urgent needs or general questions, please do not hesitate to contact the Defencely Web Security Support team at support (@) Defencely (.) com
 1. Insufficient Authentication
 2. Insufficient Authorization
 3. Integer Overflow
 4. Remote File Inclusion (RFI)
 5. Buffer Overflow
 6. Brute force
 7. Content Spoofing
 8. Information Leakage
 9. Server Misconfiguration
 10. Directory Indexing
 11. Improper file system permission
 12. Session Prediction
 13. Improper Input Handling
 14. Http Request/Response Splitting
 15. LDAP Injection
 16. Path Traversal
 17. SSI Injection
 18. URL Redirect
 19. Failure to restrict URL Access
 20. Insecure Indexing
 21. Local File Inclusion (LFI)
 22. Sensitive Data
 23. Sensitive Directory
 24. Insecure Cryptography Storage
 25. Insecure Cookie
 26. Server Response
Insufficient Authentication
This scenario occurs when a website has carelessly or wrongfully implemented account authentication protocols. Even if care was taken to ensure maximum compliance with account login procedures, new methods are always being developed to attempt to subvert the system, so future upgrades and updates are necessary to minimize the impact of such exploits.
What happens with insufficient authentication? The security system at the back end of your website will fail to properly authenticate users, hence assisting attackers in carrying out their ruthless campaigns. Some online businesses have a very sensitive nature – a fact which many conspirators actively look for in order to cause the most damage, not only in terms of information breached, but in terms of goodwill, trust and reputation for the company affected.
'Insufficient Authentication' in itself, involves several layers of potential breaches from harmless to severe. Therefore, it's crucial to have an understanding of the resources the attacker is using to gain unlawful entry into the site, and how to anticipate future breaches and exploits so that the site in question remains continuously protected.
Take a specific URL of the website as a perfect example of an attacker's agenda. If the hacker were to use a brute force attack, the said URL could lead to a "domino effect"; compromising the file directories at the server end, admin accounts, admin account contents, fellow user accounts and vice versa.
Example – Insufficient Authentication Commonly Overlooked
Being the very first category of WASC, our experience has been that the 'Insufficient Authentication' application is one that's commonly overlooked – ironic, isn't it? In many instances, webmasters do not expect anyone to access the /admin/ directory of their websites because it is not linked to any URL; an extremely risky security flaw of its own.
It takes only minimal research for an attacker to discover and compromise this directory which can then ripple out to affect other portions of the site. Therefore, taking proper steps to enforce authentication protocols, even on pages that have no direct path or content, is vital to keeping the rest of the site secure.
Insufficient Authorization
Closely related, but not similar to, the first WASC category: 'Insufficient Authentication, caters to weakly implemented authorization modules on a website, server, web app or anything remotely linked to the internet.
Consider a user performing an action at your website, which is consistent with the security policies of your business. In this context, relevant authorization levels need to be called so that the user can move on about his/her business easily. The user won't see any restricted content or be privy to information that should not be available to them at their current level. Proper authorization protocols are so entrenched in our everyday web activities, that it can be easy to overlook when something has gone wrong.
If the same user is authenticated with poorly defined authentication/access levels, and has malicious intent in mind, they may be able to easily gain unauthorized access to private, confidential or business-critical information and then use or sell this information for their own benefit.
Practical Example of 'Insufficient Authorization'
URLs that do not adhere to the "security through obscurity" methods often reveal the underlying data identifiers. For instance:
http://example.com/RecordView?id=12345
The above URL reveals the user ID as 12345 at the end of its string. If the concerned user with this ID is not assigned the proper read / write rights, he could access sensitive information displayed or "intentionally hidden by default" at that URL.
Now, if you apply the same concept to entire online company databases, data stacks and other crucial infrastructure data, you can now easily imagine the magnitude of damage caused by this particular WASC vulnerability.
Integer Overflow
As a result of an arithmetic operation, such as: multiplication, subtraction, addition etc., 'Integer Overflow' attacks can occur. These arithmetic operations are carefully assessed and calculated by website security experts at the time of their implementation.
However, seeing that there will always be Zero Day Vulnerabilities, security experts often report certain cases of 'Integer Overflow' at hand. When an integer overflow attack is in question, the concerned arithmetic operation wraps the maximum value of the integer string and displays it as a whole number.
Take the example of a clock's 24 Hour time format against 12 Hour time format. "13:00" hours will be displayed as "1:00 because of the arithmetic subtraction and wrapping of the number: 12.
Likewise, the 8 bit signed integer in computer architecture has a maximum value of 127 and a minimum value of -128. At the time of creating an application, a website or a program, if the "expert" neglects the addition of only 1 number and uses it to round off 127, an integer overflow will occur sooner or later.
Remote File Inclusion (RFI)
(RFI is an attack technique which is used by exploiters to dynamically attack core mechanisms of a website, or a web app for that matter. In cases where the web app or the website is taking user side URL parameter inputs, the attacker intercepts these requests, changes them, and then sends them across.
At the website's end, the RFI edited files are treated the same way as a user side request is. However, the resultant factors are very damaging. Websites support file inclusion because of their framework nature.
Remote file inclusion attacks are normally used for, but not limited to:
• Execute malicious codes on the server. These codes are a result of added or edited command lines in the original file. In severe cases, complete system compromise can be seen easily.
• Client side files are intercepted and tampered with. The attacker manipulates the content of these local files. When the client sends them to the server, such as session cookies, the attacks are then executed successfully.
An Example of RFI Attacks Can be PHP Files:
Consider this code:
$incfile = $_REQUEST["file"];
include($incfile.".php");
In the above lines, the first one will extract the complete value of the file parameter that was generated as a result of HTTP request. The second line is connected to the first one. Its purpose is to dynamically set the file name so that it can be included using the values that are extracted.
Such information plays a vital role into helping attackers understand nature of websites, webpages or anything that is connected to the internet.
Buffer Overflow
Basically, Buffer Overflow is kind of a WASC module that's treated as a flaw occurring in data memory blocks. When more data is written in a memory block than it can hold, the buffer that's supposed to allocate a specific amount of memory to that block, overflows.
The attacker spots these buffers and exploits them to his advantage, hence it allows:
• Process Execution Control
• Crash Processes
• Modification of Internal Variables
Many different types of attacks can be leveraged using these security holes. The primary objective of the attacker is to control the target process via buffer overflow.
Brute force
Perhaps the worse and the most unethical attacks of their kind, Brute force security breaches have always been of highest concern for security experts.
As the name implies, a Brute force attack involves potentially millions of concurrent connections on a website. Since no website can realistically handle so much traffic bombarding the server at once, this opens up the floodgates for an attacker to gain entry.
One very common example is user password detection. Let's say an 8 character alphanumeric bit has 2.8 million possibilities of a correct password. Even with this in mind, people select their passwords from much smaller subsets – things like "password", "admin123" and so forth which, in return, makes them prone to such attacks.
User education on selecting the proper type of password, and built-in security measures such as requiring upper and lower case, numbers or special characters can only go so far to protect the user's account. Security checks must also be implemented on the server side if brute force attacks are to be mitigated successfully.
Content Spoofing
In this WASC category, malicious attackers use different injection techniques to insert malicious payloads into a misrepresented website or a web application.
The misleading content tricks users into redirects, hence making them install malware, viruses disguised as common applications (such as Adobe flash) or having them input their personal information that could be later on used to compromise the victims. Content spoofing is commonly used on fake sites where transactions and pertinent user financial details can be compromised, including spoofs of Paypal, airline ticket reservation sites, package delivery services, banks and more.
Information Leakage
Information leakage pertains to a weakness in a web application or a complete website wherein directories or files are not correctly hidden, thus revealing sensitive information that was supposed to be protected and private.
Information leakage attacks have significant impact on any online or offline platform. This data can be used by attackers for several purposes, ranging from extortion, blackmailing, to credit card fraud and identity theft or worse.
In its common forms, information leakage mainly occurs whenever there is a failure to scrub out HTML comments that contain confidential info. Other elements that contribute to information leakage are server misconfiguration, insufficient authorization, improper application configuration and etc.
The failure to scrub HTML or Scripts can help attackers gain access to file directory structure, server side data, SQL query structure and internal network information. The developers, while working on HTML projects, often leave scrubbing aside because it's one of those nagging little things that usually gets tossed aside when the pressure to launch gets in the way.
Such developers assume that there is no harm in leaving inline comments during project handling and therefore unknowingly leave doorways wide open for hackers. It is crucial to remove these comments and other notes before launching the website, making a certain software go public or before revealing a web page to others.
Moving on, webpages that provide different responses, based on the authorization of user or the validation of data, can also be cause for leaking information.
Some forms of sensitive data include:
- Account Info
- Passport Numbers
- Credit Card Numbers
- Session Addresses
- SSNs (Social Security Numbers)
- Driver's License Numbers
In these cases, proper security is essential to ensuring users have the proper access, rights and authorization while keeping private information safe.
Server Misconfiguration
Most of the time, servers are filled with user account info, password details and many other things that are meant for either the developers, or web admins to access. When a failure to lock such information at server side occurs due to misconfiguration, it could lead to unforeseen consequences.
Likewise, misconfigured or properly configured, but, outdated SSL certifications, encryption settings and other relevant details can lend themselves to this category of WASC attack. Server misconfiguration attacks are a result of exploits and weaknesses detected at the server side of any online or offline business.
Indeed, this kind of attack is often a result of poorly implemented settings and strategies that later on lead to a domino effect of cascading levels of severity. It is strongly advised that while configuring servers, do not rely on default sample files, default directory locations and such other things if you will be dealing with confidential user details, private account information and other content which must be kept secure.
Directory Indexing
In the context of automated directory listing, the server will list all the files that are present within a directory structure. By default, these files are indexed in:
• Index.HTML
• Home.HTML
• Default.ASP
• Default.ASPX
• Index.PHP
If the above files are not present, the automated approach can still call the directory structure. In normal circumstances, visitors going to any website, simply type the site's URL.
Meanwhile, the server processes that URL request by looking into the relevant directory of the website, so that the content could be displayed as an output.
If that webpage or the main page of the website is not there, the server lists the directory listing, hence sending the full output to the end user. The results are primarily processes as "Is" argument, if the server is using Unix OS, or the "Dir" argument, if the server is using Windows OS.
However, the client/ user calling the URL, only sees the results interpreted in HTML format. The attacker uses countermeasures to detect these vulnerabilities and plot campaigns accordingly.
Improper file system permissions
Improper file system permissions are more of a threat rather than a vulnerability in and of themselves. These permission errors occur when the developers are not careful enough to properly implement file access permissions while working on a project.
What makes it even worse is the potential capabilities of beta testers who are supposed to detect file permission related vulnerabilities on firsthand basis. When incorrect file system permissions are available, the attacker gets to access the restricted file on an online system. It would be akin to giving a burglar the keys to your home and telling him exactly where your valuables are stored.
Following are some of the permissions associated with sensitive and insensitive files of any given website or web application:
- Read
- Write
- Modify
- Execute
- List Folder Contents
- Traverse Folder
- List Folder
- Read Attributes
- Read Extended Attributes
- Create Files/Write Data
- Create Folders/Append Data
- Write Attributes
- Write Extended Attributes
- Delete Subfolders and Files
- Delete Read Permissions
- Change Permissions
Session Prediction
The attacker initially establishes trust, by interacting with the victims' website/forums as a regular user. Afterwards, with a little bit of impersonation, sensitive information is hijacked more or less through identification of particular session logs.
In technical lingo, known as Session Hijacking, the attacker has the ability to issue website requests with compromised user privileges. Most of the websites online today do not adhere to this WASC module. Therefore, their foundations are nearly as open as formal invitations to attackers to easily invest their skills in opening wide, severe vulnerabilities.
Users who visit websites that require a username and password, are putting their security at stake, every time they access their accounts. They submit credentials, which are transmitted as session to the server side for authentication.
The attacker targets these session IDs and accesses those accounts, while impersonating a legit user. If that particular user is granted file permissions, this could translate to a great deal of damage to the site administration, website structure, directories, sensitive files and much more.
Improper Input Handling
Input handling, when it is improper or malfunctioning, becomes the most common form of weakness on any online platform. These weaknesses are mainly identified across websites, web applications and etc.
Input handling refers to inputting of validation functions, sanitization of data, file filtering, encoding, argument handling and etc. If a web app or a website is receiving input through human users who gain access via:
• Software
• Browser Interface
• Hardware Peripherals
The input is transferred to concerned back end in different formats, such as: JSON, SOAP and etc. All input coming from users should be treated equally as non-trusted information.
Http Request/Response Splitting
Ordinarily, a browser sends HTTP requests to websites, enabling users to see the content within mere seconds. When an HTTP Request/ Response Splitting attack is in order, the same URL request is merged with XSS attacks to inflict browser cache damage.
Once infected/ poisoned, the victim's browser is forced to load those attacks that the attacker intended to execute. As a result, instead of one HTTP request, TWO requests are made, while the latter one being the malicious kind.
To date, XML HTTP Request, and HTTP Digest Authentication mechanisms must be in place for this attack to work. Not all the browsers support this type of intrusion due to a lack of forward HTTP proxy. But those that do have the forward HTTP proxy defined leave security gaps wide open for hackers to exploit.
LDAP Injection
Based on user supplied inputs, many websites use LDAP statements to operate or serve information in a better way. With LDAP injections, the attacker can use those statements to not only query the Lightweight Directory Access Protocol, but also manipulate the X.500 series directory services.
LDAP protocols run over the Transport layer of the internet. For instance, the TCP module is used by websites and web applications, alike, to use user supplied input that is later on created as custom LDAP statements.
When this user supplied information is not properly sanitized, it makes it possible for attackers to change the construction of the LDAP statement before it is finally processed at server side and then sent back to the same user.
The interruption cases security issues to occur.
Path Traversal
Those files that reside outside the web directory, are accessed on unauthorized basis through Path Traversal strategies. The attacker manipulates or exploits the URL of a website to reveal information pertaining to files stretched over entire directory structure of a server.
Many websites restrict access to specific file system and directories, otherwise known as: Web Document Root/ CGI Root Directory. These files include user access related info and other details that govern the core functionality of the website.
SSI Injection
SSI is the abbreviation of 'Server Side Include' terminology, alluding to failure of a website's improperly implemented sanitization protocols. The attacker uses server side exploits to inject data packets that are later on interpreted by site admins or site back end as valid arguments.
These arguments can also be entered into an HTML file through alteration, hence making it easier for attackers to carry on with their business. The website's server parses information before providing it to the clients requesting it.
The attacker, through submission of server side includes statements, gains the ability to compromise system commends to his own advantage.
URL Redirect
URL Redirect(s) are very commonly overlooked SNAFUs these days. Webmasters, at the time of creating or managing the website, overlook details of each and every URL that is responsible for redirecting users to specific pages of the website.
The attacker uses URL redirectors to interfere with site load balance and to record the outgoing links, to name a few form of attacks. URL redirects are overlooked because they are not really treated as security vulnerability. As a result, visitors coming to a website are often resent to other websites that possess malicious codes and etc.
Failure to restrict URL Access
These days, everyone has access to the internet, which makes it easier for attackers to execute their activities. Is there a possibility for anonymous users of your website to access a private page, or privileged information?
If yes, then your website is vulnerable to URL access based attacks. The impetrator, who would have unauthorized access to the privileged information, would use it against your business.
Websites and website security modules are not always designed to protect certain pages. On top of it, if a system misconfiguration is in order, or improper code implementation is there, it could make matters much worse.
For attackers, breaching all website user information, gaining access to all user accounts and vice versa, would be extremely easy.
Insecure Indexing/ Insecure File Indexing:
Data confidentiality is threatened in case of insecure indexing parameters. Normally, website files, or directories are intended to be hidden from public viewing. Similarly, their access is considered privileged and is not for all users coming to the website.
These indexed files have the potential of helping attackers compromise the system integrity. When these files are being indexed by the server or by the attacker, the information written in them, or on them, is retrieved by unauthorized users through a series of URL related queries.
- Example of Insecure Indexing – The Attacker Finds Hidden Files:
The attacker suspects that some kind of information is stored on the website. This information is to be revealed to someone later on. If the attacker knows the publishing process of the website content, he will know the nature of the file upload process.
Thus, knowing that the file is already uploaded on the server, but not linked to any actual page, the attacker sends local requests to onsite search engine. If the file is indexed somewhere, it will be revealed, with a possibility that the attacker can download it and use it for negative purposes.
Local File Inclusion (LFI):
LFI is short form of Local File Inclusion, It is process of including files on server through you web browser, This vulnerability head up when page include is not properlt sanitized,And Allows Directory Traversal to be injected,
An Example of LFI Attack Can be PHP File
<?php
$file = $_GET['file'];
if(isset($file))
{
Include("page/$file");
}
else
{
include("index.php");
}
?>
A legal request made to script is look like :
http://yourexample.com/index.php?file=home.php
With little use of potential attacker, who is likely to be interested in the files out of page or directory to make it happen attacker could use LFI
http://yourexample.com/index.php?file=../../../../../../etc/passwd
Sensitive Data
Under normal circumstances, the server handles most of the files; directory structure and application function at its own side. Given that there are times when an application needs to be updated, or even the platform that the main website is running through, a set of batch files or backup files is created as a consequence of those actions.
These backup files are targeted by cyber attackers because of their sensitive nature. The threats under this attack category range over, but are not limited to the following:
- When unreferenced files, lying on the server side are disclosing information that could facilitate the attacker into doing something harmful. Immediately delete unwanted files of such nature or create a backup at a secure location.
- When pages containing powerful functionality are used to attack a specific site side application. Examples are compromised admin accounts that are not linked to live content, but are still active somewhere on the website.
- Old collection of "outdated" backup files of any website. These files contain vulnerabilities that were listed and then fixed in the revised version. File names, such as; "ViewDoc.Old.XXX" are a target usually.
- Entire web archives or directories that are "obscured" but are not relocated. Web admins take such matters lightly, which later on, costs them a heft expense at the hands of any attacker who has experience compromising web archives. Even a single file can contain a list of other file locations spread all over the server.
Sensitive Directory
Under normal circumstances, the server handles most of the files; directory structure and application function at its own side. Given that there are times when an application needs to be updated, or even the platform that the main website is running through, a set of batch files or backup files is created as a consequence of those actions.
These backup files are targeted by cyber attackers because of their sensitive nature. The threats under this attack category range over, but are not limited to the following:
- When unreferenced files, lying on the server side are disclosing information that could facilitate the attacker into doing something harmful. Immediately delete unwanted files of such nature or create a backup at a secure location.
- When pages containing powerful functionality are used to attack a specific site side application. Examples are compromised admin accounts that are not linked to live content, but are still active somewhere on the website.
- Old collection of "outdated" backup files of any website. These files contain vulnerabilities that were listed and then fixed in the revised version. File names, such as; "ViewDoc.Old.XXX" are a target usually.
- Entire web archives or directories that are "obscured" but are not relocated. Web admins take such matters lightly, which later on, costs them a heft expense at the hands of any attacker who has experience compromising web archives. Even a single file can contain a list of other file locations spread all over the server.
Insecure Cryptography Storage
If your online business or website caters to specific number of users who are part of the system, this OWASP vulnerability category needs to be taken care of.
Think of protecting the system against users that have access to sensitive data, or internal website admins. Attackers don't raise any alarms under this attack category. They silently carry on with their activities; breaching information, whistleblowing, stealing vital data – so on and so forth.
By encrypting data, rotating keys, strong algorithm and implementation of such protocols, insecure cryptography can be avoided easily. Failure to implement these protocols can result in expensive recovery strategies, reputation management and entire remodeling of website security modules.
Insecure Cryptography Storage Impact on Businesses and Websites:
Possible impacts include, but are not limited to; putting your reputation at stake, losing your client's banking info to identity thieves, legal liabilities and long term financial injuries.
Insecure Cookie
Cookies possess great potential for online attackers who have experience in tampering with their properties. This is one of the reasons as to why browser developers and online security service providers encourage users to delete server side, and local side cookies.
The attacker targets other users, servers and any application that deals with storing cookies. The attacker detects the nature of those cookies, estimates their expiry time and then attacks accordingly. As a result, the attacker knows when the cookies were/ are set, what they are going to be used for and why they are being used for so and so purpose.
This kind of information assists the attacker in properly segmenting a strategy. These cookie attributes are key examples of insecure cookie attacks:
- Secure: Only secure requests are entertained once it is verified that the request or response if connected to HTTPS. This is a secure environment where the attacker cannot do much.
- HTTP Only – With this attribute, attacks are prevented if the attacker is intending to inject cross site scripts or anything of that nature. However, outdated java versions and security parameters will not protect the website effectively.
Cookie attribute vulnerabilities are detected and then targeted as per the attacker's intent.
Server Response
In technical terms, Server Response is very much similar to HTTP Response. Often times, visitors stumble upon a "Server Timed Out", or "Failed to Process Your Request because the Server Timed Out" kind of messages. These messages are indicator of this phenomenon.
In other words, this term is also known as "HTTP Server Response Splitting". When a cyber attack is in order, the attacker takes this split response opportunity to send a single HTTP request to the server. These requests can be sent one time, or a number of times; whatever it takes to affect the victim. The webserver is forced to develop an output stream of data, which is then interpreted by the attacker/ target as two different responses, instead of one HTTP response.
There is a probability where the attacker can control the first server side response. However, what matters is how the attacker tackles the second server response stream. The HTTP status line comes under the control of attacker targeting the victim's computer, server or any other device. The response is controlled to the last byte of HTTP body.
Once complete control is obtained, the attacker again generates two HTTP split responses and releases them to the server via the target computer/ website. The first response invokes two responses from the web server, and the second request would typically be to some "innocent" resource on the web server.
Later on, the second request is to be matched by the target, against the second HTTP response, which is fully controlled by the attacker. In layman terms, the target is tricked into believing that a particular resource on the web server (as designated by the second request) is the server's HTTP response (server side content). In reality, these responses are some malicious data chunks, which are forged by the attacker through the web server.
Possible Effects of HTTP Response Splitting Attacks:
a. With HTTP Response Splitting, it is possible to mount various kinds of attacks
It's as Simple as 1-2 -3
Step 1
Sign up with Defencely.com
Step 2
Detect & Fix
Vulnerabilities
Step 3
Stay Safe, Stay Protected
Keep Your Business Secure. Get Started Now.