How to Test Application Security – Web and Desktop Application Security Testing Techniques
The Need For Security Testing?
The software industry has achieved a solid recognition in this age. In the recent decade, however, the cyber-world seems to be even more dominating and driving force which is shaping up the new forms of almost every business. Web-based ERP systems used today are the best evidence that IT has revolutionized our beloved global village.
These days, websites are not meant only for publicity or marketing but these have been evolved into the stronger tools to cater to complete business needs.
Web-based Payroll systems, Shopping Malls, Banking, Stock Trade application are not only being used by organizations but are also being sold as products today.
This means that online applications have gained the trust of customers and users regarding their vital feature named as SECURITY.
No doubt, the security factor is of primary value for desktop applications too.
However, when we talk about the web, the importance of security increases exponentially. If an online system cannot protect the transaction data, no one will ever think of using it. Security is neither a word in search of its definition yet, nor is it a subtle concept. However, I would like to list some compliments on security.
Examples of Security flaws in an application
- A Student Management System is insecure if the ‘Admission’ branch can edit the data of ‘Exam’ branch
- An ERP system is not secure if DEO (data entry operator) can generate ‘Reports’
- An online Shopping Mall has no security if the customer’s Credit Card Detail is not encrypted
- A custom software possess inadequate security if an SQL query retrieves actual passwords of its users
Security
Now, I present to you the simplest definition of Security in my own words.
“Security means that authorized access is granted to protected data and unauthorized access is restricted”.
So, it has two major aspects; first is the protection of data and the second one is access to that data. Moreover, whether the application is desktop or web-based, security revolves around the two aforementioned aspects.
Desktop And Web Security Testing
A desktop application should be secure not only regarding its access but also with respect to the organization and storage of its data.
Similarly, web application demands, even more, security with respect to its access, along with data protection. A web developer should make the application immune to SQL Injections, Brute Force Attacks and XSS (cross-site scripting). Similarly, if the web application facilitates remote access points then these must be secure too.
Moreover, keep in mind that Brute Force Attack is not only related to web applications, desktop software is also vulnerable to this.
I hope this foreword is enough and now let me come to the point. Kindly accept my apology if you so far thought that you are reading about the subject of this article. Though I have briefly explained software Security and its major concerns, my topic is ‘Security Testing’.
Recommended Reading=> Web Application Security Testing
I will now explain how the features of security are implemented in software application and how should these be tested. My focus will be on Whats and Hows of security testing, not of security.
Recommended Security Testing Tools
#1) netsparker
=> Try the best Netsparker Security Test Tool
#2) Kiuwan
Find and fix vulnerabilities in your code at every stage of the SDLC.
Kiuwan is compliant with the most stringent security standards including OWASP, CWE, SANS 25, HIPPA, and more. Integrate Kiuwan in your IDE for instant feedback during development. Kiuwan supports all major programming languages and integrates with leading DevOps tools.
#3) Indusface WAS Free Website Malware Check
Indusface WAS provides both manual Penetration testing bundled with its own automated web application vulnerability scanner that detects and reports vulnerabilities based on OWASP top 10 and also includes a Website reputation check of links, malware and defacement checks of the website in every scan
=> Run a Quick Website Scan for Free
=> Contact us to suggest a listing here.
List Of Top 8 Security Testing Techniques
#1) Access to Application
Whether it is a desktop application or a website, access security is implemented by ‘Roles and Rights Management’. It is often done implicitly while covering functionality,
For Example, in a Hospital Management System, a receptionist is least concerned about the laboratory tests as his job is to just register the patients and schedule their appointments with doctors.
So, all the menus, forms and screens related to lab tests will not be available to the Role of ‘Receptionist’. Hence, the proper implementation of roles and rights will guarantee the security of access.
How to Test: In order to test this, thorough testing of all roles and rights should be performed.
The tester should create several user accounts with different as well as multiple roles. Then he should use the application with the help of these accounts and should verify that every role has access to its own modules, screens, forms, and menus only. If the tester finds any conflict, he should log a security issue with complete confidence.
This can also be understood as authentication and authorization testing which is very beautifully depicted in the below image:
So, basically, you need to test about ‘who you are’ and ‘what you can do’ for distinct users.
Some of the authentication tests include a test for password quality rules, test for default logins, test for password recovery, test captcha, test for logout functionality, test for password change, test for security question/answer, etc.
Similarly, some of the authorization tests include a test for path traversal, test for missing authorization, test for horizontal access control problems, etc.
#2) Data Protection
There are three aspects of data security. The first one is that a user can view or utilize only the data which he is supposed to use. This is also ensured by roles and rights
For Example, TSR (telesales representative) of a company can view the data of available stock, but cannot see how much raw material was purchased for production.
So, this aspect of security testing is already explained above. The second aspect of data protection is related to how that data is stored in the DB.
All the sensitive data must be encrypted to make it secure. Encryption should be strong, especially for sensitive data like passwords of user accounts, credit card numbers or other business-critical information.
Third and the last aspect is an extension of this second aspect. Proper security measures must be adopted when the flow of sensitive or business-critical data occurs. Whether this data floats between different modules of the same application or is transmitted to different applications, it must be encrypted to keep it safe.
How to Test Data Protection: The tester should query the database for ‘passwords’ of the user account, billing information of clients, other business-critical and sensitive data and should verify that all such data is saved in encrypted form in the DB.
Similarly, he must verify that data is transmitted between different forms or screens after proper encryption only. Moreover, the tester should ensure that the encrypted data is properly decrypted at the destination. Special attention should be paid to different ‘submit’ actions.
The tester must verify that when the information is being transmitted between the client and server, it is not displayed in the address bar of a web browser in an understandable format. If any of these verifications fail, then the application definitely has a security flaw.
The tester should also check for proper use of salting (appending an extra secret value to the end input like password and thus making it stronger and more difficult to be cracked).
Insecure randomness should also be tested as it is a kind of vulnerability. Another way to test data protection is to check for weak algorithm usage.
For Example, since HTTP is a clear text protocol, if the sensitive data like user credentials are transmitted via HTTP, then it is a threat to application security. Instead of HTTP, sensitive data should be transferred via HTTPS (secured through SSL, TLS tunnel).
However, HTTPS increases the attack surface and thus it should be tested that server configurations are proper and certificate validity is ensured.
#3) Brute-Force Attack
Brute Force Attack is mostly done by some software tools. The concept is that by using a valid user ID, the software attempts to guess the associated password by trying to log in again and again.
A simple example of security against such an attack is account suspension for a short period of time as all the mailing applications like ‘Yahoo’, ‘Gmail’ and ‘Hotmail’ do. If a specific number of consecutive attempts (mostly 3) fail to log in successfully, then that account is blocked for some time (30 minutes to 24 hrs).
How to test Brute-Force Attack: The tester must verify that some mechanism of account suspension is available and is working accurately. (S)He must attempt to login with invalid user IDs and Passwords alternatively to make sure that software application blocks the accounts if continuous attempts are made to login with invalid credentials.
If the application is doing so, it is secure against brute-force attack. Otherwise, this security vulnerability must be reported by the tester.
Testing for brute force can also be divided into two parts – black box testing and grey-box testing.
In Black box testing, the authentication method employed by the application is discovered and tested. Furthermore, the grey box testing is based on partial knowledge of password & account details and memory trade-off attacks.
Click here to explore black box & grey box brute force testing along with examples.
The above three security aspects should be taken into account for both web and desktop applications while the following points are related to web-based applications only.
#4) SQL Injection And XSS (Cross-Site Scripting)
Conceptually speaking, the theme of both these hacking attempts is similar, so these are discussed together. In this approach, the malicious script is used by hackers in order to manipulate a website.
There are several ways to immune against such attempts. For all input fields of the website, field lengths should be defined small enough to restrict the input of any script
For Example, The Last Name should have field length 30 instead of 255. There may be some input fields where large data input is necessary, for such fields proper validation of input should be performed prior to saving that data in the application.
Moreover, in such fields, any HTML tags or script tag input must be prohibited. In order to provoke XSS attacks, the application should discard script redirects from unknown or untrusted applications.
How to test SQL Injection and XSS: Tester must ensure that maximum lengths of all input fields are defined and implemented. (S)He should also ensure that the defined length of input fields does not accommodate any script input as well as tag input. Both these can be easily tested
For Example, If 20 is the maximum length specified for ‘Name’ field, and input string “<p>thequickbrownfoxjumpsoverthelazydog” can verify both these constraints.
It should also be verified by the tester that the application does not support anonymous access methods. In case any of these vulnerabilities exist, the application is in danger.
Basically, SQL injection testing can be done through the following five ways:
- Detection techniques
- Standard SQL injection techniques
- Fingerprint the database
- Exploitation Techniques
- SQL Injection Signature Invasion Techniques
Click here to read in detail about the above ways to test SQL injection.
XSS is also a type of injection which injects malicious script into a website. Click here to explore in-depth about testing for XSS.
#5) Service Access Points (Sealed And Secure Open)
Today, businesses depend and collaborate with each other, the same holds good for applications especially websites. In such a case, both the collaborators should define and publish some access points for each other.
So far the scenario seems quite simple and straightforward but, for some web-based products like stock trading, things are not so simple and easy.
When there is a large number of the target audience, the access points should be open enough to facilitate all users, accommodating enough to fulfill all users’ requests and secure enough to cope with any security-trial.
How to Test Service Access Points: Let me explain it with the example of the stock trading web application; an investor (who wants to purchase the shares) should have access to current and historical data on stock prices. The user should be given the facility to download this historical data. This demands that the application should be open enough.
By accommodating and secure, I mean that the application should facilitate investors to trade freely (under the legislative regulations). They may purchase or sale 24/7 and the data of transactions must be immune to any hacking attack.
Moreover, a large number of users will be interacting with the application simultaneously, so the application should provide enough access points to entertain all the users.
In some cases, these access points can be sealed for unwanted applications or people. This depends on the business domain of application and its users,
For Example, A custom web-based Office Management System may recognize its users on the basis of IP Addresses and denies to establish a connection with all other systems (applications) that do not fall in the range of valid IPs for that application.
The tester must ensure that all the inter-network and intra-network access to the application is by trusted applications, machines (IPs) and users.
In order to verify that an open access point is secure enough, the tester must try to access it from different machines having both trusted and untrusted IP addresses. Different sorts of real-time transactions should be tried in a bulk to have good confidence in the application’s performance. By doing so, the capacity of access points of the application will also be observed clearly.
The tester must ensure that the application entertains all the communication requests from trusted IPs and applications only while all the other requests are rejected.
Similarly, if the application has some open access point, then the tester should ensure that it allows (if required) uploading of data by users in a secure way. In this secure way, I mean about the file size limit, file type restriction and scanning of the uploaded file for viruses or other security threats.
This is all how a tester can verify the security of an application with respect to its access points.
#6) Session Management
A web session is a sequence of the HTTP request and response transactions linked with the same user. The session management tests check how session management is handled in the web app.
You can test for session expiry after particular idle time, session termination after maximum lifetime, session termination after log out, check for session cookie scope and duration, testing if a single user can have multiple simultaneous sessions, etc.
#7) Error handling
Testing for Error handling includes:
Check for error codes: For Example, test 408 request time-out, 400 bad requests, 404 not found, etc. To test these, you need to make certain requests to the page such that these error codes are returned.
The error codes are returned with a detailed message. These messages should not contain any critical information that can be used for hacking purpose
Check for stack traces: It basically includes giving some exceptional input to the application such that the returned error message contains stack traces that have interesting information for hackers.
#8) Specific Risky Functionalities
Mainly, the two risky functionalities are payments and file uploads. These functionalities should be tested very well. For file uploads, you need to primarily test that any unwanted or malicious file upload is restricted.
For payments, you need to primarily test for injection vulnerabilities, insecure cryptographic storage, buffer overflows, password guessing, etc.
