Christophe
Forum Replies Created
-
Using some kind of proxy tool for bug hunting is massively helpful, yes. Most people use Burp Suite, though I’ve been using ZAP exclusively for a while now because I want to make a course on it so I want to understand it really well.
So, yes, if you’re not using a proxy tool yet, I’d highly recommend getting one and learning it really well.
-
While the DVWA difficulty settings are helpful in test environments to try things out, I wouldn’t necessarily think of apps you’re testing in the real world as mapping to the “Hard” or “Impossible” levels. Every app is different and some apps may have both vulnerabilities that are extremely easy to exploit, while at the same time having very difficult ones to exploit.
I know some people use the term “exotic” payloads, but I don’t really know what that means. To me, a payload is a payload. I don’t really know what would make one payload more exotic than another apart from one person’s opinion. What I’m trying to say is that having a list of various payloads you can pick from is helpful, and that list should be wide and deep because a payload that might work on one application could be completely useless on another (no matter how ‘exotic’ it is). ‘Basic’ payloads can also still be useful in testing out the application initially, to see what gets blocked, filtered, sanitized, etc…and then from there, you can narrow down payloads that are more likely to make it through.
So just because <script>alert(1)</script> is very unlikely to make it through nowadays (though I bet you could still find low-value targets that are still susceptible to that payload, unfortunately), it doesn’t always mean that the payload is completely useless. How is the application responding to the payload? Is it stripping out the words script? Is it giving you an error response? Is it stripping out the < > / but keeping script & alert(1)? It gives you clues as to what’s going on behind the scenes. Use that information to iterate and go from there.
-
Anything in particular that you have in mind?
FYI we plan on having content that covers all of the OWASP Top 10 (waiting for the new one to come out which should be soon), and HackerOne Top 10 (if there are differences in the latest lists, and also having that one be more bug bounty focused)
-
Look for areas that are less likely to have been looked at already. This might mean jumping on a program as soon as it comes out, digging deep into an application to find panels or other areas that aren’t easily found at the surface level, or using/creating tools that monitor for changes in applications.
For the last one, here’s what I mean: organizations deploy changes at different paces, but many strive to deploy frequently. Each deployment brings opportunity since things (endpoints, JS files, libraries, etc) change, sometimes things break, and new code/libraries/endpoints/etc means more things to test. By having a tool that monitors for those changes, you can get alerted and jump on it as soon as it happens – again, before others have a chance to do so.
-
I don’t think anyone can say that one approach is better than another, since it depends on too many factors including what your personal goals are. Like Hakluke mentioned in his podcast episode one of the bounty hunters making the most money on HackerOne right now is almost entirely relying on automated tools. Of course, they’ve built some of their own tooling and/or extensions for existing tools over the years, so even that requires a ton of work upfront and maintenance along the way.
If you’re mostly interested in learning and experience, then I think a combined approach is best. You don’t want to do everything manually in areas where automation can do a much better job, but you also don’t want to rely exclusively on tools since you’ll want the hands-on practice. They work hand-in-hand.
-
Burp has a built-in update chcker in the Help menu -> Check for Updates. Have you tried that?
Otherwise, you can download the latest from their website.
-
Hey Anthony, couple of answers from two different perspectives:
From the bug bounty perspective:
1- One way to avoid submitting self-XSS in bug bounty programs that don’t have a measurable impact is to think about how the vulnerability you are submitting in your report gets exploited. What actions does an attacker have to take in order to exploit this XSS vulnerability? Does it require another user’s interaction? If so, what would the user have to do to trigger it? Would they have to copy/paste the payload in their own browser console? If so, that’s self-XSS. In addition to that, think about how you would do something practical with that vulnerability. ie: here’s exactly how I would steal an admin’s credentials, or here’s how I would steal a user’s billing information.
So before I submit a report, I always try to answer – in detail – the question: “How would I successfully exploit this vulnerability if I wanted to do damage?” If I can’t answer that question in my report, my work isn’t done yet and I don’t have a proper report.
From the victim of self-XSS perspective:
2- One way to avoid being the victim of self-XSS social engineering is to never copy/paste code that someone gives you in your browser’s console unless you are 100% certain of what it does. Though honestly, this applies to copy/pasting code even outside of your browser.
-
Thanks to everyone who ended the live Q&A and posed fantastic questions. If you didn’t get a chance to attend it, click the link above for a replay.
See you at the next one!
-
Found my first vulnerability a long time ago on some old PHP website before I even knew the term ethical hacking existed (probably didn’t actually), and it was by accident if I recall correctly, so not sure that counts for what you’re asking.
Hesitant to respond though because if you’re asking to compare yourself to others, I’m not sure how useful that is 🙂
Everyone learns and does things in their own time!
-
I’m not sure for all of the others, but I do know that XSStrike does have WAF detection and evasion capability. Doesn’t mean it will always be successful, but it’s at least a start. Once you know what WAF is sitting in front of the application, you can 1) research its weaknesses, and 2) try different payloads and see what gets blocked and what makes it through…then go from there, iterating until something works. This is a time-consuming process unless you get lucky.
From personal experience, I’d say finding XSS is going to be more likely than SQL injection and command injection, at least for bug bounty programs. XSS consistently comes out on top in HackerOne’s list of top 10 vulnerability bounty awards. That doesn’t mean that will always be the case, but it has been for at least the last couple of years. So while it might be true that organizations are getting better and better at preventing XSS (which is great), the data shows that there is still a long way to go.
The other thing is that most public programs have already had a lot of eyeballs on them by the time they become public. A lot of programs start out as private, invite-only, and later on (months or years later) sometimes become public. So finding easy vulnerabilities in public programs is going to be difficult unless you jump on the program as soon as it comes out. With that said, hackers are lazy and a lot of them will move on to a different program after checking for low-hanging fruit. Use that to your advantage – sign up for the free tier (or maybe even pay for an account if it’s not too much $) and access portals/endpoints that likely didn’t get anywhere near as much attention as the public marketing website would have. Thinking from a developer’s mindset, that’s also probably where less care was taken for security. “Only customers will access this, and why would customers try to hack us/their own data?” This is a very common mindset, and I’ve heard many variations of that said over the past few years. Use that to your advantage.
With all of that said, I’d encourage you to take a step back for a moment: bug bounty hunting is hard. It takes a serious amount of time and commitment for most to make headway. Given the time limitations you’ve mentioned in other posts and what looks like a growing frustration, maybe you should take a break from it for a little bit and come back later. Even some of the more popular bounty hunters openly talk about needing to take breaks (months at a time) in between programs. In my opinion, it should be a fun experience. Sure, it will cause frustration, but overall you should be enjoying the hunt of it and overcoming roadblocks and challenges. When it starts deviating from that, I think that’s when it’s time to take a break.
-
You shouldn’t lol. First off, you probably should stop talking to people if they’re putting you down. You don’t need that kind of negativity in your life when you’re just trying to learn and make a living.
Second, if something is making you money, then you do you. As long as it’s ethical and you’re having fun, who cares what others call it?
-
It really depends and I don’t think there’s necessarily a hard and fast rule. If it’s a client engagement, there should be some kind of defined timeline or scope, so that takes care of that. But if you’re talking about open bug bounties, you’ll see some people stick to a handful of big targets and they focus on those exclusively. Others will only spend a little bit of time per target but go after more targets.
Personally, I tend to do better with targets that I’m personally interested in. Maybe it’s a product that I personally use or have used in the past, or that I know friends use. Since it’s more interesting, I might spend more time on that target even if I’m not finding anything at first.
There was one recently that I *really* wanted to find a security bug on because it’s a product that I use and have known about for a long time. I couldn’t find anything for 2 weeks. The third week, I popped a stored XSS. It could have been 4 more weeks before I found it, or I may have never found it at all. Not knowing is part of what makes this field challenging for sure.
-
Nice! Thanks for the step-by-step @sechvn !
-
hmm that’s odd. A workaround in the meantime would be to download the latest straight from github, and then you can just pull updates from that repository over time
-
Please do keep us posted! I’d love to hear about your progress, and like I said, I’m here if you have any questions!