10%

Try : Insurtech, Application Development

Edtech(5)

Events(31)

Interviews(10)

Life@mantra(10)

Logistics(1)

Strategy(14)

Testing(7)

Android(42)

Backend(28)

Dev Ops(2)

Enterprise Solution(20)

Frontend(28)

iOS(39)

Javascript(13)

AI in Insurance(25)

Insurtech(57)

Product Innovation(34)

Solutions(13)

Augmented Reality(7)

Customer Journey(7)

Design(6)

User Experience(21)

Artificial Intelligence(94)

Bitcoin(7)

Blockchain(14)

Cognitive Computing(7)

Computer Vision(6)

Data Science(13)

FinTech(41)

Intelligent Automation(25)

Machine Learning(43)

Natural Language Processing(10)

[Part 1] Web Application Security Testing: Top 10 Risks & Solutions

By :
14 minutes, 17 seconds read

Mantra Labs organized a conference at their Bangalore office, where their seasoned Test Engineer Rijin Raj discussed the current top 10 web application security risks in the evolving digital world. He elaborated on vulnerabilities with examples and offered suggestions to avoid them.

The Open Web Application Security Project (OWASP) is an international organization for enhancing the security of web applications. The top 10 web application security risks worldwide are:

  1. Injection
  2. Broken authentication and session management
  3. Cross-site scripting
  4. Indirect object security reference
  5. Security misconfiguration
  6. Sensitive data exposure
  7. Missing function level access control
  8. Cross-site forgery
  9. Using components with known vulnerabilities: Heartbleed and Shellshock
  10. Unvalidated redirects and forwards

To get an idea about how hackers are exploiting web applications and prevailing security/penetration bugs, you can go through the exploit database’s list. Now let’s delve deep into the risks and web application security testing measures.

1. Injection

Here, an attacker sends rogue content to a web application interpreter resulting in executing authorized commands. The most common forms of code injection attacks are SQL Injection ( or SQLi). An SQLi attack sends malformed code into the database server, leading to exposure of your data. This style of attack is so simple that anyone with access to the internet can do it. In fact, SQLi scripts are available for download. 

How is SQLi or Injection attack done?

The attacker enters characters — “” into the search field and presses the button. It leads to an error page that displays more information than required. The following example shows a badly and insecurely programmed application that is not capable of handling SQL Injections. 

Just a few illegal characters with a little sniffing around leads the hacker to this string: “‘ union select password from users;”. He can then implement this finding to harvest usernames and passwords from the database. This is just one basic way to exploit application databases.

Commonly used tools for detecting & preventing SQL Injection attacks

SQLmap: It is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking-over of database servers. It is commonly used in Kali-linux.

After finding a vulnerable page you can find database by typing:

sqlmap –u (url) –dbs

Tip: You can use the Hackers Arise guide on how to use SQLmap.

For web application security testing practice, you can use the following websites:

  • http://www.shumka.com/shumka-at-50/news/index.php?id=847
  • http://waytogonatural.com/product_detail.php?ID=4526

You can also find SQL vulnerable websites on your own. You just have to look for:

  • php?id=(any Number)
  • login.php?id=(any number)
  • index.php?id=(any number)

Also, go through these examples of SQLi attacks: blind SQL Injection attack, SQL Injection vulnerability.

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.

Key Points to check if you are vulnerable:

  1. Unprotected user authentication credentials while storing using hashing or encryption.
  2. Possibility of guessing or overwriting credentials because of weak account management functions (e.g., account creation, change password, recover password, weak session IDs).
  3. Exposed Session IDs in the URL (e.g., URL rewriting).
  4. Session IDs are vulnerable to session fixation attacks.
  5. Session IDs don’t timeout, or user sessions or authentication tokens, particularly single sign-on (SSO) tokens, lack of proper invalidation during logout.
  6. Passwords, session IDs, and other credentials are sent over unencrypted connections.
  7. Session IDs aren’t rotated after successful login.

Examples of broken authentication attack scenarios

Scenario #1

Airline reservations application supports URL rewriting, putting session IDs in the URL. 

http://example.com/sale/saleitems?sessionid=268544541&dest=Hawaii

An authenticated user of the site wants to let his friends know about the sale. He e-mails the above link without knowing he is also giving away his session ID. When his friends use the link they will use his session and credit card.

Scenario #2

An application’s timeouts aren’t set properly. A User uses a public computer to access a site. Instead of selecting “logout” the user simply closes the browser tab and walks away. Attacker uses the same browser an hour later, and that browser is still authenticated.

Scenario #3

Insider or external attacker gains access to the system’s password database. User passwords are not properly hashed, exposing every users’ password to the attacker.

Check vulnerability to ‘Sensitive Data exposure’

  1. Are you storing any crucial data in clear text long term, including backups of this data?
  2. Are you using any old / weak cryptographic algorithms?
  3. Check if you’re transmitting any of the data in clear text, internally or externally? Internet traffic is especially dangerous.
  4. Are weak crypto keys generated, or is proper key management or rotation missing?
  5. Are any browser security directives or headers missing while providing sensitive data to the browser? (Nikto)

Web application security testing and prevention from Sensitive data exposure

  1. Make sure you encrypt all sensitive data .
  2. Don’t store sensitive data unnecessarily. Discard it as soon as possible. No one can steal the data that you don’t have, right?
  3. Ensure using strong standard algorithms and strong keys.
  4. Make sure proper key management is in place.
  5. Ensure storing passwords with powerful password protection algorithms such as bcrypt, PBKDF2, or scrypt.
  6. Disable autocomplete on forms collecting sensitive data and disable caching for pages that contain sensitive data.

How to protect your application against broken authentication and session management?

Password strength:

  • Define minimum size and complexity. Complexity depends on the usage of combinations of alphabetic, numeric, and/or non-alphanumeric characters.
  • Change password periodically
  • Prevent reusing previous passwords.

Password use:

  • Restrict to a small, finite number of login attempts per unit of time and log repeated failed login attempts.
  • System should not indicate whether it was the username or password that was wrong if a login  attempt fails.

Password change controls:

  • Ask users to provide both their old and new password while changing their password.
  • If your system emails forgotten passwords to users, ask users to re-authenticate whenever they’re changing their email address. Otherwise, an attacker who has won temporary access to their session (e.g. by walking up to their computer while the actual user is logged in) can simply change their email address and request an email for ‘forgotten password”.

Password storage:

  • Store passwords in either hashed or encrypted form.
  • Use encryption whenever plain text password is required.

Session ID protection:

  • Protect the entire user session via SSL.
  • Never include Session ID in the URL as they can be cached by the browser.
  • Session IDs should be long, complicated, random numbers that are impossible to guess.
  • Change Session IDs frequently during a session to reduce how long a session ID is valid. One should also change Session IDs when switching to SSL, authenticating or other major transitions.

Browser caching:

  • Never submit authentication and session data as part of a GET. Always use POST method.
  • Always mark authentication pages with all varieties of the no cache tag to prevent someone from using the back button in a user’s browser and backup to the login page and resubmit the previously typed in credentials.

Also, refer to these examples of broken authentication and session management: Bad 2FA activation flow, Coursera application loophole.

3. 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.

By leveraging XSS, an attacker does not target a victim directly. Instead, he exploits a vulnerability within a website or web application that the victim would visit; essentially using the vulnerable website as a vehicle to deliver a malicious script to the victim’s browser. There are basically two types of XSS:

  1. Stored XSS
  2. Reflected XSS

Stored XSS

  • 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. 
  • 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

  • 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.
  • 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.

How to test for XSS injection vulnerabilities?

You can determine if a web-based application is vulnerable to XSS attacks very easily. Take a current parameter that is sent in the HTTP GET request and modify it. Take for example the following request in the browser address URL bar. This url will take a name parameter that you enter in a textbox and print something on the page. Like “Hello George, thank you for coming to my site” http://www.yoursite.com/index.html?name=george 

Now, modify it so as to add an additional information to the parameter. For example try entering something similar to the following request in the browser address URL bar.

http://www.yoursite.com/index.html?name=<script>alert(‘You just found a XSS vulnerability’)</script> 

If this pops up an alert message box stating “You just found a XSS vulnerability”, then you know this parameter is vulnerable to XSS attacks. I.e. you’ve not validated the parameter name and it is allowing anything to be processed as a name, including a malicious script that is injected into the parameter passed in. 

Basically what is occurring is normally where the name George would be entered on the page the </script></script> message is instead being written to the dynamic page.

More on XSS vulnerability and examples — hackersonlineclub.com

You can use Zaproxy, a freeware tool for web application security testing. Also, you can use Burp Suite and Beef for XSS vulnerability testing.

4. Indirect object security reference

An attacker can access a reference to a file or directory and manipulate that reference to gain unauthorized access to other objects (unless an access control check is in place).

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. 

Vulnerability to insecure direct object references

  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?

How to test insecure direct object references?

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.

The best way to test insecure direct object references is — take at least two users to cover different owned objects and functions. For example, take two users with each having access to different objects (such as purchase information, private messages, etc.), and (if relevant) users with different privileges (for example administrator users). Now see whether there are direct references to application functionality. By having multiple users the tester can save valuable testing time in guessing different object names as he can attempt to access objects that belong to the other user.

Examples of insecure direct object references

The value of a parameter directly retrieves a database record. 

Sample request: http://foo.bar/somepage?invoice=12345

  • 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.
  • 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. 
  • To test for this case the tester should obtain the identifier of an invoice belonging to a different test user (ensuring he is not supposed to view this information per application business logic), and then check whether it is possible to access objects without authorization.

You can refer to these reported cases — deleting a member of any organization, reset password.

Many web applications use and manage files as part of their daily operation. Using poorly designed/deployed input validation methods, an aggressor can exploit the system in order to read or write private files.

Web application security testing techniques for validation bypassing attack

In order to determine which part of the application is vulnerable to input validation bypassing, the tester needs to enumerate all parts of the application that accept content from the user. Here are some examples of the checks to be performed at this stage:

  1. Are there request parameters which could be used for file-related operations?
  2. Are there unusual file extensions?
  3. Is there interesting variable names?

Consider the following strings-

http://example.com/getUserProfile.jsp?item=ikki.html

http://example.com/index.php?file=content

http://example.com/main.cgi?home=index.htm

An attacker can insert the malicious string “../../../../etc/passwd” to include the password hash file of a Linux/UNIX system. This kind of attack is possible only if the validation checkpoint fails. According to the file system privileges, the web application itself must be able to read the file.

http://example.com/getUserProfile.jsp?item=../../../../etc/passwd

It is also possible to include files and scripts from external websites.

http://example.com/index.php?file=http://www.owasp.org/malicioustxt

While accepting protocols as arguments, as in the above example, it’s also possible to- 

  • probe the local filesystem: http://example.com/index.php?file=file:///etc/passwd
  • probe local or nearby services: http://example.com/index.php?file=http://localhost:8080 or http://example.com/index.php?file=http://192.168.0.2:9080

Refer to this example of path traversal — Full Path Disclosure by removing CSRF token

5. Security misconfiguration

Improper server or web application configuration leads to various flaws.

  • Debugging enabled
  • Incorrect folder permissions
  • 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?

Security misconfiguration attack scenarios

Scenario #1: The app server admin console is automatically installed and not removed. Default accounts aren’t changed. Here, the attacker can discover standard admin pages on your server, logs in with default passwords, and take over.

Scenario #2: Directory listing is not disabled on your web server. An attacker can simply list directories to find any file. The attacker finds and downloads all your compiled Java classes, which they decompile and reverse engineer to get all your custom code. Attacker, thus, finds a serious access control flaw in your application.

Scenario #3: App server configuration allows returning stack traces to users, potentially exposing underlying flaws such as framework versions that are highly vulnerable.

Scenario #4: App server comes with sample applications that are not usually removed from your production server. These sample applications have well known security flaws that attackers can use to compromise your server.

How to protect against security misconfigurations?

Follow these 8 measures to protect your application against security misconfiguration attacks.

  1. Install latest updates and security patches. Have an easy to manage updating process with test environments to check updates before deploying to production environments.
  2. Remove sample applications that ship with content delivery systems and web frameworks. Most tools that help build web applications include demo and sample code to help teach developers how to use the tools and starter toolkits. These apps are a known target for anyone attempting to compromise web application security.
  3. Remove unused features, plugins and web pages. Only include the parts of web applications that you need for your services to end users. 
  4. Turn off access to setup and configuration pages. Don’t leave the setup and configuration pages available for external users.
  5. Change usernames, passwords and ports for default accounts. Web application frameworks and libraries often ship with default administration names, passwords and access ports enabled. Everyone knows these. Change all these to non standard usernames, passwords and ports.
  6. Don’t share passwords between accounts on Dev, Test and Production systems. 
  7. Don’t use the same administration accounts and settings across your Dev, Test and Production systems.
  8. Turn off debugging so as to prevent sending internal info back in response to test queries or errors. Excessive debugging information can let attackers glean information about a web applications configuration.

Also read – Security Misconfiguration: Hardening your ASP.NET App

We’ll discuss the remaining 5 web application security risks and testing for vulnerability in the part 2 of this series.

Go to – Web application security testing part 2

About the author: Rijin Raj is a Senior Software Engineer-QA at Mantra Labs, Bangalore. He is a seasoned tester and backbone of the organization with non-compromising attention to details.

Related:

Cancel

Knowledge thats worth delivered in your inbox

8 Best Ways to Reduce Android App Size

5 minutes, 29 seconds read

With the increase in mobile storage spaces that have gone up to 256 GB, app size is also growing. App size is sure to grow as developers are adding new features, trying to meet customer needs, and also trying to support their apps on various screen sizes. Around 74% of the world uses Android, and 70% of users consider app size before installing them. Moreover, as humans are getting accustomed to instant gratification, they ponder on ways to download apps as they take up storage spaces. Despite the cloud support for photos, videos, and files, android users face issues, such as mobile hanging due to app size. As customer expectations are increasing, android app developers are considering other ways to reduce app size while still incorporating significant additional features and keeping in mind the customer experience.

Below are the 8 best ways to reduce android app size:

1. Use Android App Bundle to Reduce App Size

When generating the release version of your app, you can choose between APK and Android App Bundle.  The second option will make Google play to generate the APK with only those features a specific user need. 

Use Android App Bundle

App Bundle Vs APK

Android App Bundle

  • It is a publishing format that includes compiled code and resources of your app, and delays APK generation and signing to Google Play.
  • With Android App Bundles, the compressed download size restriction is 150 MB. The app bundle cannot be used with APK expansion files.
Android App Bundle
Important: In the second half of 2021, new apps will be required to publish with the Android App Bundle on Google Play. New apps larger than 150 MB must use either Play Feature Delivery or Play Asset Delivery.

How to build android app bundles?

To build app bundles, follow these steps:

  1. Download Android Studio 3.2 or higher—it’s the easiest way to add feature modules and build app bundles.
  2. Add support for Play Feature Delivery by including a base module, organizing code and resources for configuration APKs, and, optionally, adding feature modules.
  3. Build an Android App Bundle using Android Studio. You can also deploy your app to a connected device from an app bundle by modifying your run/debug configuration and selecting the option to deploy APK from app bundle. Keep in mind, using this option results in longer build times when compared to building and deploying only an APK.
  4. If you’re not using the IDE, you can instead build an app bundle from the command line.
  5. Test your Android App Bundle by using it to generate APKs that you deploy to a device.
  6. Enroll into app Play App Signing. Otherwise, you can’t upload your app bundle to the Play Console.
  7. Publish your app bundle to Google Play.

Please note: Android Package Kit – As per developer console, by the mid of 2021, developers won’t be able to upload apk on play store)

  • Android operating system uses APK which is the package file format for distribution and installation of mobile apps, games and middleware. APK is similar to other software packages such as APPX in Microsoft Windows or a Debian package in Debian -based operating systems.
  • Google Play requires that the compressed APK downloaded by the users should not exceed 100 MB.
  • The expansion files for your app are hosted by Google Play which serves them to the device at no cost to you. The expansion files are saved to the device’s shared storage location (the SD card or USB-mountable partition).

2. Use Proguard

Proguard is probably one of the most useful tools to reduce your APK size. It reduces the source code files to a minimum and can reduce the APK file size upto 90%.

  • Use it in all variants whenever using “Proguard”
  • Helps to avoid conflict at the of generate apk or bundle if will use in all the variants.
  • We cannot let ProGuard rename or remove any fields on these data classes, as they have to match the serialized format. It’s a safe bet to add a @Keep annotation on the whole class or a wildcard rule on all your models.

3. Use Android Size Analyzer Plugin

This Android Studio plugin will provide you recommendations to reduce the size of your application.

With the APK Analyzer, you can accomplish the following:

  • View the absolute and relative size of files in the APK, such as the DEX and Android resource files.
  • Understand the composition of DEX files.
  • Quickly view the final versions of files in the APK, such as the AndroidManifest.xml file.
  • Perform a side-by-side comparison of two APKs.

There are three ways to access the APK Analyzer when a project is open:

  • Drag an APK into the Editor window of Android Studio.
  • Switch to the Project perspective in the Project window and then double-click the APK in the default build/output/apks/ directory.
  • Select Build > Analyze APK in the menu bar and then select your APK.

More details at: Jetbrains

4. Optimize Your App’s Resources

Whether used or not, every resource takes up memory. It is therefore necessary to have only those resources that you need, and to use those in a memory efficient way. In other words, you should consider the resolution of the image before finalizing on it.

5. Optimize Libraries

As large libraries consume huge amounts of space, it is advisable to remove parts of it in case you do not need them and if it is permitted by the license of the library. Proguard can aid you in this process but it is not always able to remove large internal dependencies.

6. Use Vector Graphics Wherever Possible

They are sharp and do not consume much space as they rely on mathematical calculations and not on pixels that need to be saved. However, they cannot be used for photography.

7. Compress Your Images

By using tools such as pngcrush, you can reduce the file size of PNG images. It is advisable to do this images as they still look the same. 

8. Only Support Specific Densities

If only a small portion of users use a specific density, it might be better to let Android scale your other densities for them as it would reduce your APK size.


As mobile storage space is growing, people are installing a large number of apps to meet a wide range of needs. But as app size is increasing, people are continuing to struggle with storage issues. With provisions such as Proguard, one can compress the APK file size and optimize libraries easily. Compressing images and using vector graphs are also useful in reducing app size.

About the author: Anand Singh is Tech Lead at Mantra Labs. He is integral to the company’s Android-based projects and enterprise application development.

Further Reading:

Cancel

Knowledge thats worth delivered in your inbox

Loading More Posts ...
Go Top
bot

May i help you?

bot shadow

Our Website is
Best Experienced on
Chrome & Safari

safari icon