Timeline for How to deal with a company that doesn't fix (potential) security vulnerabilities in their web app?
Current License: CC BY-SA 4.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 26, 2019 at 9:19 | comment | added | Moritz W. | A possible exploitation I see here is XSS, right? With no input validation I could maybe get some kind of script injected, that will simply read the password from the local storage. Then I could drop it off to the unrestricted file upload on their server and wouldn't even have to worry about CORS. So it wouldn't even be necessary to recover something from someones hardware to get access to the stored password... | |
| Dec 26, 2019 at 2:36 | comment | added | Steve Jessop | So they're going to think "this problem is really niche, because for practical purposes local storage is considered secure. After all, we use cookies for session tokens, which also can be used to hijack accounts". Whereas they should be thinking, "just don't store plaintext passwords: it's dumb regardless of the fact that you do store other sensitive data in the same place". | |
| Dec 26, 2019 at 2:31 | comment | added | Steve Jessop | The difficulty (as I see it) with that is, although it's terrible to store and re-use the password like that, it's not stone-cold exploitable because in some sense it's not categorically worse than having a plaintext password briefly in RAM on the user's machine. Because, RAM goes to swap goes to theoretically recoverable by someone who gets hold of the hardware later, just as "data in local storage which you make some feeble effort to delete at end of session", is theoretically recoverable. It's easier than from swap, but it's not like I can read your local storage any time I like. | |
| Dec 25, 2019 at 18:29 | answer | added | user171968 | timeline score: 0 | |
| Dec 25, 2019 at 17:23 | history | edited | schroeder♦ | CC BY-SA 4.0 |
deleted 260 characters in body; edited title
|
| Dec 25, 2019 at 11:31 | comment | added | Moritz W. | No there are no credit card payments accepted. I think that all the data is stored in one table, due to the user id being an auto increment value and I could inspect the user IDs for different gyms, which suggested that these auto increment are all within the same range. Apparently the application is hosted over AWS, but they are maintaining the PHP install themselves. Since they are using the "Zend" Framework the passwords are probably hashed. But they are storing the user password in the browser and every time you reload the page a login request is sent with the stored password. | |
| Dec 25, 2019 at 10:44 | comment | added | user1067003 |
The user password is stored in the local storage in plain text that's a huge red flag, and almost guarantees that they're also vulnerable to timing attacks. combine that timing vulnerability with infinite retries and you can probably get into any account. (do their password verification scheme use $input!=$password ? then they're vulnerable. do they use hash_equals(hash("sha256",$input,true),hash("sha256",$password,true)) ? then they're not vulnerable)
|
|
| Dec 25, 2019 at 2:25 | comment | added | user3757614 | There's a good chance that when they declared the bugs "fixed", they really meant that the bugs are fixed in the source control, and next time they redeploy, these fixes will be applied. If you assume that the fixes got merged a few days back, it could easily be a month before you could see any differences. While immediate fix of security issues would be nice, it's nearly Christmas, and these are not obviously critical. | |
| Dec 25, 2019 at 1:34 | comment | added | Pedro Lobito | How do you know the passwords are stored in clear text? | |
| Dec 25, 2019 at 1:09 | comment | added | MrWhite | "20,000 customers stored in .... one big table" - how have you been able to determine this? "I could get most of the user data into my hands within a few days" - That would seem to suggest a far more serious vulnerability than what you have listed? | |
| Dec 25, 2019 at 0:39 | comment | added | Dai | Is this a self-hosted system - or a SaaS system? Vulnerabilities in self-hosted systems are more difficult to deal-with - but that also limits the total amount of damage that can be done (assuming each install of the self-hosted system might be using a recent PHP version, a more recent release of the software, etc). | |
| Dec 24, 2019 at 21:37 | history | became hot network question | |||
| Dec 24, 2019 at 21:06 | answer | added | averell | timeline score: 6 | |
| Dec 24, 2019 at 21:00 | history | tweeted | twitter.com/StackSecurity/status/1209579645433208832 | ||
| Dec 24, 2019 at 15:58 | comment | added | mti2935 | Does the company accept credit card payments at this site? If so, they are required to be PCI compliant, and the site should display an indication that they are PCI compiant - usually in the form of a badge bearing the name of a third-party PCI verification company, such as Trustwave, TRUSTe, McAfee, etc. Does the site accept credit card payments, and if so, does it bear such a badge? | |
| Dec 24, 2019 at 13:14 | comment | added | Moritz W. | For me to get a feeling how serious this issue is. Maybe this web app would be a valuable target to an attacker. | |
| Dec 24, 2019 at 13:07 | vote | accept | Moritz W. | ||
| Dec 24, 2019 at 13:01 | comment | added | Sjoerd | Why do you ask "And would you consider these problems/vulnerabilites critical?" Why does it matter if we think these problems are critical or not? What does "critical" mean for you? | |
| Dec 24, 2019 at 12:58 | answer | added | Sjoerd | timeline score: 12 | |
| Dec 24, 2019 at 12:50 | review | First posts | |||
| Dec 24, 2019 at 17:04 | |||||
| Dec 24, 2019 at 12:46 | history | asked | Moritz W. | CC BY-SA 4.0 |