QualiTest Tests Web & Mobile Vulnerability for Digital Wallet Company

QualiTest Tests Web & Mobile Vulnerability for Digital Wallet Company

QualiTest tested the web and mobile interfaces for a digital wallet company.  Was it free of vulnerabilities?  No.  But now the 50 threats we found have been addressed.

Client Overview

The client is a digital wallet company, using an AWS cloud-based PCI-DSS Platform-as-a-Service.


Business Needs and Objectives

The client wanted to know what safety risks existed in their website and mobile apps.  Financial is the second-most frequently hacked industry, only beaten by healthcare.  They required help performing web and mobile application penetration testing. The current requirement is to perform mobile application vulnerability testing for website, iOS, and Android applications.


The QualiTest Solution

QualiTest, the world’s largest outsourcing provider specializing purely in software testing, has a lot of experience when it comes to website cyber security penetration testing. Our technique includes providing a list of recommendations that includes a summary of the kind of problem, the vulnerable URL(s), execution (what happened), fix (including common traps to avoid when doing this kind of patch), and a sample attack request/response at the data level.  Our testing did center on, but not limit itself to, the OWASP Top 10 list.  We found 50 vulnerabilities, including 2 critical ones and 12 high-priority ones.  Vulnerabilities leaned slightly more heavily towards Android and away from iOS, with web being in the middle.  The cyber vulnerabilities we found included:


  • Log file too verbose – Critical Severity User log files are helpful for recording history that can be analyzed later like an airplane’s black box, but they should not be capturing sensitive data like credit cards and passwords. The print statements that build the logs should be altered to omit any sensitive data.
  • HTML5: CORS (Cross-Origin Resource Sharing) – High Severity 2 locations for iOS and 4 web URL’s were found which allowed access from any domain, meaning that any domain can perform 2-way interaction with the app via this request. If another domain used the fine-grained CORS policy, that domain could potentially provide a vector of attack to other users of the app.  Even if an allowed domain is not overtly malicious, security vulnerabilities within that domain may allow an attacker to exploit the trust relationship and attack the app that allows access.  What’s needed is to remove any inappropriate domains from the CORS policy.
  • Security patches are not updated – High Severity The remote host is missing one or more security patches. We will provide you with a list of what needs updation.
  • Open Ports – High Severity This plugin is a SYN ‘half-open’ port scanner. It shall be reasonably quick even against a firewalled target. Note that SYN scans are less intrusive than TCP (full connect) scans against broken services, but they might cause problems for less robust firewalls and also leave unclosed connections on the remote target, if the network is loaded.  Protect your target with an IP filter.
  • Debuggable flag – High Severity The Android: debuggable flag is manually set to True, causing your app to be debuggable in production builds. This can result in data leakage and other security issues. Instead of setting the debuggable flag in the manifest, set Debug made to False.
  • Weak Hashing – High Severity The app uses Java Hash Code, a weak hash function that should never be used in a Secure Crypto Implementation. SHA-1 is a weak hash known to have hash collisions, and uses an insecure random number generators.  25 separate Java executables require fixing.
  • Cleartext submission of password – High Severity A password transmitted over unencrypted connections is vulnerable to interception. An attacker must be suitably positioned to eavesdrop on the victim’s network traffic over an insecure connection such as public wifi, or a corporate or home network shared with a compromised computer.  An attacker situated in the user’s ISP or the app’s hosting infrastructure could also perform this attack.  Even if the app itself only handles non-sensitive data, exposing passwords puts users who re-use their passwords elsewhere at risk.  Applications should use transport-level encryption (SSL or TLS) to protect all sensitive communications passing between the client and the server, and if HTTP cookies are used for transmitting session tokens, the secure flag should be set to prevent transmission over clear-text HTTP.
  • Password submitted via HTTP GET method – High Severity Some apps use the HTTP GET method to submit passwords, which are transmitted within the query string of the requested URL. Sensitive data within URL’s may be logged in various locations, including the user’s browser, the web server, and any forward or reverse proxy servers between the 2 endpoints.  They may even show on-screen, bookmarked or emailed around by users.  The Referer header may disclose this to 3rd parties when off-site links are followed.  At this web service level, passwords should only be submitted using the POST method.
  • Password field with autocomplete enabled – Low Severity Most browsers are capable of remembering user credentials for HTML forms. Both the user and the application have configuration control of this ability.  Stored credentials can be captured by an attacker who gains control over the user’s computer, and an attacker who finds a separate application vulnerability such as cross-site scripting may be able to exploit this to retrieve a user’s browser-stored credentials.
  • SQL Injection – Low Severity A particular parameter that is expecting a numeric string allows that payload to be concatenated with “or 8127=8127” or “or 8127=8128”. By accepting malformed parameters, queries may get built where the embedded logic concept of “OR TRUE” or “OR FALSE” may lead to all database entries being revealed.  Parameterization can prevent malformed strings from altering the logic of a constructed SQL command.