Qualitest Tests Website Vulnerabilities for an Entertainment Company
Qualitest was asked to test the website for one of India’s biggest entertainment groups. Was it found to have no vulnerabilities? No. But now they can relax knowing that their risks have been identified and successfully fixed.
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
- HTML5: CORS (Cross-Origin Resource Sharing) Functionality Abuse – Medium Severity
- 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.