Client Overview

 The client is one of India’s biggest entertainment groups.

Business Needs and Objectives

The client wanted to know what safety risks existed in their website, which includes the abilities to register and login, and to make reservations and purchases.  They required performing mobile application penetration testing for the Native app. The current requirement is to perform mobile application vulnerability testing for iOS applications.

The Qualitest Solution

Qualitest has a lot of experience when it comes to Security Testing.  The effort took 3 days of preliminary preparation, 3 days of planning and analysis, 8 days of security assessment execution and validation, 2 days of reporting, and 2 days of closure.  Our recommendations include a summary of the kind of problem, the vulnerable URL, execution (what happened), fix (including common traps to avoid when patching), and a sample attack request/response at the data level.  We base our testing on the OWASP top 10 mobile vulnerability list.  We found 26 vulnerabilities in our first pass, and 16 in our second pass.  The vulnerabilities we found included:

  • SQL Injection– High Severity
    SQL injection vulnerabilities arise when user-controllable data is unsafely used in database SQL queries. Crafted input (in this case a single quote in the RowNo parameter) can break out of the data context and interfere with the surrounding query’s structure. This can deliver damaging attacks, including reading or modifying critical app data, interfering with app logic, escalating privileges within the database and taking control of the database server.
  • External Service Interaction – High Severity
    This occurs when an app can be induced to interact with an arbitrary external service, like a web or mail server. The ability to trigger external services does not constitute a vulnerability, but it usually indicates a vulnerability with serious consequences. The ability to send such requests can allow the vulnerable server to be used as an attack proxy. By submitting suitable payloads, an attacker can cause the app server to attack other systems that it can interact with. It is possible to induce the app to perform server-side DNS lookups of arbitrary domain names.
  • Cross Site Scripting – High Severity
    Reflected cross-site scripting vulnerabilities arise when a request’s data echoes in the app’s immediate response. An attacker can construct a dangerous request that, if issued by another app user, will execute the attacker’s JavaScript code within the user’s browser during their app session. This can steal the victim’s session token or login, perform arbitrary actions on the victim’s behalf, or log their keystrokes.  The attacker can induce the user to issue the attacker’s crafted request by sending the victim a link containing a malicious URL in an email or instant message, submitting the link to popular web sites that allow content authoring (in blog comments, say), or creating an innocent looking web site that causes viewers to make arbitrary cross domain requests to the vulnerable app via GET or POST.
  • HTML5: CORS (Cross-Origin Resource Sharing) Functionality Abuse – Medium Severity
     8 target website resources were found sharing across websites using CORS with an open access control policy. An overly permissive CORS policy allows  malicious apps to talk to the  victim app, which can lead to spoofing, data theft, relay and other attacks, possibly compromising the entire domain. Imagine a private internet resource, with a universal access policy created with the intent that only other intranet  domains can reach it. An internal employee browses an Internet resource with  malicious embedded JavaScript enabling external  accessibility, effectively exposing it to the Internet, then escalating into a data breach.
  • Cross Domain Post – Informational
    Apps sometimes use POST requests to transfer sensitive information between domains. This does not necessarily constitute a security vulnerability, but it creates a trust relationship between the two domains. Data transmitted between domains should be reviewed to determine whether the originating app should be trusting the receiving domain with this information. A customer payment form had this exposure.
  • Email Address Disclosed – Informational
    Email addresses in app responses may not constitute a security vulnerability, and may intentionally display contact information, and many apps (such as web mail) include arbitrary third-party email addresses within their core content. However, email addresses of developers and other individuals (both on-screen and within page source) may provide attackers with usernames for high-level access at the app’s login or names for social engineering attacks against the firm’s personnel. Unnecessary or excessive email address exposure may also increase the volume of spam emails received, possibly with phishing schemes.
  • txt – Informational
    The file robots.txt is used to give instructions to web robots, such as search engine crawlers, about locations within the web site that robots are allowed, or not allowed, to crawl and index. While robots.txt may not be a security vulnerability, it may identify restricted or private areas of a site’s contents, like a treasure map.  If the app relies on robots.txt to protect access to these areas without alternate access control, then this presents a serious vulnerability.
  • User Credentials are sent in clear text – Medium Severity
    User credentials are transmitted over an unencrypted channel. This information should always be transferred via an encrypted channel (HTTPS) to avoid interception by malicious users. A third party could read the user credentials by intercepting an unencrypted HTTP connection.  HTTP should be changed to HTTPS so that only encrypted data is being transmitted between user and server.
  • Login page password guessing Attack – Low Severity:
    A common threat web developer’s is a password-guessing attack known as a brute force attack, which tries to discover a password by systematically trying every possible combination of letters, numbers, and symbols until discovering the correct one that works. The login page doesn’t protect against password-guessing attacks (brute force attacks). It’s recommended to implement an account lockout after a defined number of incorrect password attempts.