Security Testing For Web Services

What is Security Testing in Web application?

In modern web-based applications, the usage of web services is inevitable, and they are prone for attacks as well. Since the web services request fetch from multiple websites developers have to take few additional measures in order to avoid any kind of penetration by hackers. Web services security technical procedures applied to the system to ensure the confidentiality, integrity, and availability of information that is exchanged by the Web service.

Purpose of Security Testing in Web Application

The purpose of a security test is to discover the vulnerabilities of the web application so that the developers can remove these vulnerabilities from the application and make the web application and data safe from any unauthorized action.

Securing the Web Server

Web servers are vulnerable; we need methodologies to prevent from attacks. But why do we need to focus on web application to prevent attacks or exploits? Regardless of the OS that our web server uses being IIS, .net or Apache, security configuration must be performed at this level to diminish the vulnerability levels. The main threats to a Web server are, Profiling, denial of service, unauthorized access, lack of privileges set up, arbitrary code execution, viruses, worms, and Trojan horses.

Web Service Security Testing Framework

This web services security testing framework follows a similar progression to the majority of software testing projects with the addition of a threat modelling phase. When used as part of a security assessment, it is suggested that the major phases of the framework be executed linearly. In instances where this framework is adopted as part of the testing process within the development lifecycle, regression testing may require that the test execution phase be completed multiple times as required.



The framework begins with threat modelling to produce a threat profile necessary to understand potential system risks. The threat profile facilitates scoping of the required tests and later aids in planning and test execution. After a scope definition is created, planning takes place based on the defined scope and nature of potential threats. Once a test strategy and a test plan are available, the core test execution phase can begin. This phase has been divided into a number of key test areas:

1. Information Gathering
2. Fuzzing
3. Injection
4. Confidentiality & Integrity
5. Logging
6. Logic Flaws
7. Authentication & Authorisation
8. Availability

Finally, the results of these tests are used to generate a report or reports relevant to both a business and technical audience.

Common Threats to Web Services

There are few internet security threats are injection and authentication flaws, XSS, insecure direct object references, security misconfiguration, sensitive data exposure, a lack of function-level authorization, CSRF, insecure components, and unfiltered redirects.

1. Injections/SQL Injection:
Injections are basically known as SQL Injection. When SQL statements are dynamically created as software executes, there is an opportunity for a security breach: if the hacker is able to break perimeter security and pass fixed inputs into the SQL statement, then these inputs can become part of the SQL statement. SQL injections can be generated by inserting spatial values or characters into SOAP requests, web form submissions or URL parameters. If the hacker knows his SQL, he can use this technique to gain access to privileged data, login to password-protected areas without a proper login, remove database tables, add new entries to the database, or even login to an application with admin privileges.

2. Broken Authentication and Session Management:
Incorrect implementation of authentication schemes and session management can allow unauthorized users to assume identities of valid users. Broken Authentication and Session Management attacks are anonymous attacks with an intention to try and retrieve passwords, user account information, IDs and other details.
A common attack against authentication pages is a brute force attack. A brute force attack is where an attacker will attempt multiple usernames and passwords until they obtain access to a valid account. This type of attack can be easier to perform if the application has a user enumeration or has a weak password policy.

3.Sensitive Data Exposure
When Developers sorting any crucial data in cleat text long term, including backups of this data. Second thing is that when the developers using any old / weak cryptographic algorithms, or he is not doing proper key management then the sensitive data can be expose. It can be possible if  any browser security directives or headers missing while providing sensitive data to the browser.

4. XSS- Cross-site scripting

This happens when a browser unknowingly executes scripts to hijack sessions or redirect to a rogue site.
Cross-site Scripting (XSS) refers to client-side code injection attack wherein an attacker can execute malicious scripts (malicious payload) into a legitimate website or web application. XSS is amongst the most rampant of web application vulnerabilities and occurs when a web application uses unvalidated or unencoded user input within the output it generates. An attacker does not target a victim directly, Instead, he exploits a vulnerability within a website or web application that the victim would visit.
There are basically two types of XSS:
1. Stored XSS
2. Reflected XSS


Stored XSS
a. A Stored Cross-site Scripting vulnerability occurs when the malicious user can store an attack which will be called at a later time upon some other unknown user. 
b. The storage of a method could involve a database, or a wiki, or blog. The attack executes when the unknowing user encounters the attacker’s malicious stored program. The stored method not only has the problem of incorrect checking for input validation, but also for output validation. If you’re sanitizing data during input, you should also check it for output processes. By checking and validating the output data, you can also uncover unknown issues during the input validation process.

Reflected XSS
a. The malicious user, once discovering a field within a website or web application holding XSS vulnerability, crafts a way to execute something malicious to some unknown user. This gives a chance to Reflected XSS vulnerabilities. Here, an unknown user is directed to a XSS vulnerable web application executing the attack.
b. The attacker crafts the attack using  a series of url parameters that are sent via a url. The malicious user then sends his/her malicious url with the url parameters to unknowing users. This is typically sent by email, instant messages, blogs or forums, or any other possible methods.

5. Insecure direct object references (IDOR):

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. 
For this category of web application security testing, a Tester first needs to map out all locations in the application where user input is used to reference objects directly (e.g. database rows, files, application pages, etc.). Next, the tester should modify the parameter value for reference objects and assess whether it is possible to retrieve objects belonging to other users or otherwise bypass authorization.

For Example
The value of a parameter directly retrieves a database record. 

Sample request: http://foo.bar/somepage?invoice=12345
1. In this case, the value of the invoice parameter is used as an index in an invoices table in the database. The application takes the value of this parameter and uses it in a query to the database. The application then returns the invoice information to the user.
2. Since the value of invoice goes directly into the query, by modifying the value of the parameter it is possible to retrieve any invoice object, regardless of the user to whom the invoice belongs. 

1. For direct references to restricted resources, does the application fail to verify that the user is authorized to access the exact requested resource?
2. If the reference is an indirect reference, does the mapping to the direct reference fail to limit the values to those authorized for the current user?

6. Security Misconfiguration

Improper server or web application configuration leads to various flaws.

1. Debugging enabled
2. Incorrect folder permissions
3. Using default accounts or passwords

Vulnerability to Security Misconfiguration
It’s better to check if your application is missing the proper security hardening across every part of the application stack including-

1. Check for any out-of-date software (OS, Web/App Server, DBMS, applications, APIs, and all components and libraries).
2. Are any unnecessary features enabled or installed (e.g., ports, services, pages, accounts, privileges)?
3. Are default accounts and their passwords still enabled and unchanged?
4. Does your error handling reveal stack traces or other overly informative error messages to users?
5. Are the security settings in your application servers, application frameworks (e.g., Struts, Spring, ASP.NET), libraries, databases, etc. not set to secure values?

7. CSRF

A CSRF attack forces an authenticated user (victim) to send a forged HTTP request, including the victim's session cookie to a vulnerable web application, which allows the attacker to force the victim's browser to generate request such that the vulnerable app perceives as legitimate requests from the victim.

Threat Agents: Anyone who can load content into your users and browsers and thus force them to submit a request to your websites.
Attacker’s Approach: Attackers creates forged HTTP Requests and tricks a victim in to submitting them via images, tags, XSS, or numerous other techniques.
Security Weakness: CSRF take advantage the fact that most web apps allow attackers to predict all the details of a particular action.
How to spot: Detection of CSRF flaws is fairly easy via penetration testing or code analysis.
Technical Impact: Attackers can trick victims into performing any state changing operation the victim is authorized to perform.
Business Impact: The impact to your reputation.

8. Broken Functional Level Authorization

Do NOT, under any circumstance, assume that the users are unaware of special/hidden URLs or APIs. 
Broken Function Level Authorization relates to the security issues arising due to improper validation of the authorization level of the user of an API and the function that it is intended to perform. ... As an example, consider an application with an API that allows the creation and updating of a user account and role.

Oditek as a Leading Security Testing Services Company

Web applications are considered the most exposed and least protected, thereafter vulnerable because the standards somehow are not focused on security but more in the serve need functionality. Security threats are more common than before because the internet has become today's economy most valuable tool for everyone. So there is indeed need to protect our resources, data and user privacy information.
As technology move forward and brings new strategies, tools, models and methods to increase security levels, hackers will be part of this never end game. Regarding the penetration test we can conclude that web application security tools are a fundamental component in the security process but the known security vulnerabilities by their nature can be consider complex and created by real intellectual minds with the “code” word written in their forehead, this is why we need the best minds armed with great tools to eliminate these weaknesses in a cost-effective way.

Please reach out to us on security testing needs by sending an email to info@oditeksolutions.com