4 ms·

Have to disagree with a few points here. "Hmmm, let me 'test' random website X for something that could cause a DoS" The author was testing reflected XSS whic

Have to disagree with a few points here. "Hmmm, let me 'test' random website X for something that could cause a DoS" The author was testing reflected XSS which is inherently client side, there should be no case of concern for DoS here. "Building a "security portfolio" against websites is a stupid idea with some potentially huge negative consequences." The author mentions Apple, Linkedin, Amazon and AT&T all of which have some type of vulnerability notification program. (See https://bugcrowd.com/list-of-bug-bounty-programs/ https://bugcrowd.com/list-of-bug-bounty-programs/ for a great list of programs) I would have to say that as long as the researcher was performing within the scope of the respective program, there should be no worry. I think it's the exact opposite of a stupid idea. Building out a portfolio within the scopes of the programs is a great way to build some security reputation.

billyhoffman 13y ago
I understand what you are saying, but I disagree with the risk/reward. Yes, the author was testing with a reflected XSS attack string, and yes "there should be no case of concern for DoS". But that's exactly my point. You have no idea what effect that will have. I personally have caused an inadvertent DoS attack with an XSS probe while doing a security audit for a large SaaS company. (The attack made the code throw and exception and some of my escaping characters caused havoc with their error logger, sending it into a infinite loop trying to log data, pegging the CPU and growing memory until the disk thrashed.) You don't know what you actions will cause because the server/app is a black box. And if you want to audit that, you should have a formal agreement with the company that they know what you are doing and its OK. A generic, flimsy, non-personal "everyone can try and 'hack' us and it's OK" policy published somewhere is just too little protection, especially given how the CFAA is applied in courts today.
- algorithm_dk 13y ago
  Then what is the purpose of bug bounties in your perspective?
  - billyhoffman 13y ago
    I think bug bounties can make the risk/reward ratio palatable, by either lowering risk or increasing the reward. If a company offers monetary awards for web vulnerabilities in their site, that's a good sign. It shows they recognize the monetary value on what you are doing and made the decision to reward you. It shows the extent of their commitment to the bounty program that they have allocated budget and have accepted the added accounting challenges to provide money for issues. It also means that have thought through exactly what they are expecting and what they are willing to pay. In my eyes, someone offering marketing swag or "putting your name on a web page" doesn't think your work is as valuable. Thus they are more likely to be angry and seek legal remedies should your testing cause them harm in some way, because in their eyes the value of your security testing or your findings doesn't out weight the damage. In short, all of this is an indicator of how much thought was put into the company's policy on finding and reporting security issues, and how mature their reaction will be to things they have not thought of or bad things happen. The less mature, the more likely they are to decide your testing was "unauthorized" and to seek legal remedies. Compare Spotify's policy [1] with Google's Policy[2]. Which one has put more thought and planning into running a program like this? Obviously people's risk/reward appetites differ... Please note that I am taking the risks of bug bounties/"its ok to audit us" policies that apply public websites. The Stripe/Matasano challenges are specially created systems and are always a great thing to do. [1]- https://www.spotify.com/dk/about-us/contact/report-security-issues/ https://www.spotify.com/dk/about-us/contact/report-security-... [2]- http://www.google.com/about/appsecurity/reward-program/ http://www.google.com/about/appsecurity/reward-program/
- anglebracket 13y ago
  >The attack made the code throw and exception and some of my escaping characters caused havoc with their error logger Heh, something similar happened to me during a recent audit. I didn't even know until an admin emailed me saying that I'd broken a bunch of batched jobs, and not to test that until it was fixed. >A generic, flimsy, non-personal "everyone can try and 'hack' us and it's OK" policy published somewhere is just too little protection It hasn't worked out too badly for me. I stay away from industries with lots of "suits" (banking, etc,) but if a company is implicitly encouraging independent pentesting by publicly crediting reporters, and you act in good faith, I can't see any charges sticking.

billyhoffman 13y ago

I understand what you are saying, but I disagree with the risk/reward. Yes, the author was testing with a reflected XSS attack string, and yes "there should be no case of concern for DoS". But that's exactly my point. You have no idea what effect that will have. I personally have caused an inadvertent DoS attack with an XSS probe while doing a security audit for a large SaaS company. (The attack made the code throw and exception and some of my escaping characters caused havoc with their error logger, sending it into a infinite loop trying to log data, pegging the CPU and growing memory until the disk thrashed.) You don't know what you actions will cause because the server/app is a black box. And if you want to audit that, you should have a formal agreement with the company that they know what you are doing and its OK. A generic, flimsy, non-personal "everyone can try and 'hack' us and it's OK" policy published somewhere is just too little protection, especially given how the CFAA is applied in courts today.

algorithm_dk 13y ago
Then what is the purpose of bug bounties in your perspective?
- billyhoffman 13y ago
  I think bug bounties can make the risk/reward ratio palatable, by either lowering risk or increasing the reward. If a company offers monetary awards for web vulnerabilities in their site, that's a good sign. It shows they recognize the monetary value on what you are doing and made the decision to reward you. It shows the extent of their commitment to the bounty program that they have allocated budget and have accepted the added accounting challenges to provide money for issues. It also means that have thought through exactly what they are expecting and what they are willing to pay. In my eyes, someone offering marketing swag or "putting your name on a web page" doesn't think your work is as valuable. Thus they are more likely to be angry and seek legal remedies should your testing cause them harm in some way, because in their eyes the value of your security testing or your findings doesn't out weight the damage. In short, all of this is an indicator of how much thought was put into the company's policy on finding and reporting security issues, and how mature their reaction will be to things they have not thought of or bad things happen. The less mature, the more likely they are to decide your testing was "unauthorized" and to seek legal remedies. Compare Spotify's policy [1] with Google's Policy[2]. Which one has put more thought and planning into running a program like this? Obviously people's risk/reward appetites differ... Please note that I am taking the risks of bug bounties/"its ok to audit us" policies that apply public websites. The Stripe/Matasano challenges are specially created systems and are always a great thing to do. [1]- https://www.spotify.com/dk/about-us/contact/report-security-issues/ https://www.spotify.com/dk/about-us/contact/report-security-... [2]- http://www.google.com/about/appsecurity/reward-program/ http://www.google.com/about/appsecurity/reward-program/
anglebracket 13y ago
>The attack made the code throw and exception and some of my escaping characters caused havoc with their error logger Heh, something similar happened to me during a recent audit. I didn't even know until an admin emailed me saying that I'd broken a bunch of batched jobs, and not to test that until it was fixed. >A generic, flimsy, non-personal "everyone can try and 'hack' us and it's OK" policy published somewhere is just too little protection It hasn't worked out too badly for me. I stay away from industries with lots of "suits" (banking, etc,) but if a company is implicitly encouraging independent pentesting by publicly crediting reporters, and you act in good faith, I can't see any charges sticking.