3 ms·
You've got to be kidding me. Despite the policy difficulties of running a site like this (when is someone dead?, how long until release of secrets?, how to dea
by steakejjs 12y ago
You've got to be kidding me.
Despite the policy difficulties of running a site like this (when is someone dead?, how long until release of secrets?, how to deal with lack of access to emails? etc), This site is completely insecure.
https://www.deathswitch.com/members/myaccount.php https://www.deathswitch.com/members/myaccount.php
is vulnerable to a CSRF hijack through the update email page. This literally took 20 seconds to find...who knows what would happen if I dedicated an entire minute.
In fact, there are no CSRF tokens on the entire site at all. There are big problems in these services and the policies that run them. Technical solutions might not be the best to use here. Perhaps a legal solution is the best route...
edit: I gave it 20 more seconds. Stored XSS. If I paid the money for premium service which allows file upload I'll bet I can RCE too. This is just not the type of person I want protecting my secrets.
- cfpg 12y ago> when is someone dead?, how long until release of secrets? After the recurring payments stop coming through?
- steakejjs 12y agoUnfortunately that is too simple. These are secrets. People forget to update credit cards in sites all the time and you're going to immediately shoot an email off on a failed CC transaction or when you cancel a credit card hastily? An email containing secrets? There's a lot that can go wrong that has to be thought up before-hand and debugging in production for this type of service is completely unacceptable.
- joshmn 12y agoAlso sitting atop of BlueHost. Not that there's anything wrong with (what's likely) shared hosting, but it doesn't paint the best picture. To the author: Your idea is good, but it was executed poor, and it's not a <need> by any means. If it is, the logistics of it are too damn difficult to warrant your service (or any service that does this, for that matter).
- chk 12y agoCan I ask how you identify issues like this so quickly? I'm an infosec student, and I'd love to hear what your thought process is when briefly looking over the security of a certain website.
- steakejjs 12y agoI've got a lot of practice breaking things. CSRF can be identified really fast by checking for unique tokens. Some unguessable token should be submitted with each state changing request. If not, attackers can steal authenticated accounts by making a request to the "change PW" or "change email" URLs. It's a little confusing at first. XSS I just set JavaScript as something that shows up in a field on a different page. The RCE I mentioned is just uploading a PHP file for the "file upload" feature associated with messages. If he puts the uploaded file within the webroot (and the file is php since his whole site is php) then the file will be executed when you go to its URL Web app security is something that infosec professors don't talk about at all (in my experience). I had to teach myself but OWASP is very good to get started. It also helps to write a lot of software as well since you'll tend to find pitfalls of doing things wrong edit: If you would like to see more of the technical how-tos behind CSRF check this link out. It is a blog I wrote about CSRF and how one would actually attack someone with it. http://ejj.io/csrf-password-bruteforce/ http://ejj.io/csrf-password-bruteforce/