Back in February I found an Android application which is used by the emergency services, that had exposed Azure API keys within the application leading to potential compromise of sensitive incident reports, attachments, and infrastructure server “.vhd” files with the access level to spin up new instances or delete them. I immediately reported this to the application developer and it’s respective organisation under responsible disclosure, which resulted in an instant and prompt response, which I give huge kudos for.
OWASP Defines this class of vulnerability as “Insecure Data Storage”:
Insecure data storage vulnerabilities occur when development teams assume that users or malware will not have access to a mobile device’s filesystem and subsequent sensitive information in data-stores on the device. Filesystems are easily accessible. Organizations should expect a malicious user or malware to inspect sensitive data stores. Rooting or jailbreaking a mobile device circumvents any encryption protections. When data is not protected properly, specialized tools are all that is needed to view application data .
I’ve been a user of the mobile/web application named “GoodSAM App” which is an application where the Ambulance service in London or the East Midlands can dispatch “Responders” who are trained in Basic Life Support (BLS) and can be dispatched to cardiac arrests or other priority calls and users at emergencies can also request a “Responder”. Now this application is absolutely brilliant in the nature of what it does and I fully support them.
Despite this however, I did find two vulnerabilities within the application that may have been overlooked. Specifically Cross Site Request Forgery (CSRF) within the “Account Profile” page, along with Cross Site Scripting (XSS) within the same page, the account profile page being loaded upon login.
Now typically, CSRF and XSS issues on their own are not that much of a critical vulnerability in the grand scheme of things, however in this instance it was possible to chain both CSRF/Stored XSS vulnerabilities to set the XSS payload within the account profile fields and then steal the user cookie every time they login or view the page.
Finally, as the GoodSAM Data Protection section said they take data protection seriously, I thought I would not have any problems getting these vulnerabilities resolved under responsible disclosure, however I was wrong on this occasion and have had to release the information. (See Disclosure Issues section).
“We take your data protection extremely seriously. We are registered with the Information Commissioners Office (no: ZA094052) and our technology team take the security of our data and servers very seriously. “
Recently I have been looking for vulnerabilities such as XSS/CSRF within online applications and came across an XSS vulnerability within the Major League Basketball (MLB) website, which in question was vulnerable to reflected XSS. I did attempt responsible disclosure through Open Bug Bounty  and attempted contact via Twitter also, with no response returned and hence full disclosure.
In particular, the website was vulnerable within the “FORM_CODE” parameter with the payload of “–!><Svg/Onload=confirm(‘ OPENBUGBOUNTY’)>” being used to exploit the reflected XSS vulnerability. (See below).