A list of questions that bounty hunters frequently DM me about. 😄
I have a simple philosophy that I share with everyone:
- Learn to make it. Then break it!
- Read books. Lots of books.
require 'pipeline/tasks/base_task' | |
require 'pipeline/util' | |
require 'nokogiri' | |
class Pipeline::AltDNSScanner < Pipeline::BaseTask | |
Pipeline::Tasks.add self | |
include Pipeline::Util | |
def initialize(trigger, tracker) | |
super(trigger, tracker) | |
@name = 'AltDNSScanner' |
GitHub repositories can disclose all sorts of potentially valuable information for bug bounty hunters. The targets do not always have to be open source for there to be issues. Organization members and their open source projects can sometimes accidentally expose information that could be used against the target company. in this article I will give you a brief overview that should help you get started targeting GitHub repositories for vulnerabilities and for general recon.
You can just do your research on github.com, but I would suggest cloning all the target's repositories so that you can run your tests locally. I would highly recommend @mazen160's GitHubCloner. Just run the script and you should be good to go.
$ python githubcloner.py --org organization -o /tmp/output
Broken Link Hijacking (BLH) exists whenever a target links to an expired domain or page. Broken Link Hijacking comes in two forms, reflected and stored. This issue has been exploited in the wild numerous times, but surprisingly few researchers actively look for broken links in bug bounty programs.
This post aims to give you a basic overview of the different issues that could possibly arise if a target links to an expired endpoint.
(?i)((access_key|access_token|admin_pass|admin_user|algolia_admin_key|algolia_api_key|alias_pass|alicloud_access_key|amazon_secret_access_key|amazonaws|ansible_vault_password|aos_key|api_key|api_key_secret|api_key_sid|api_secret|api.googlemaps AIza|apidocs|apikey|apiSecret|app_debug|app_id|app_key|app_log_level|app_secret|appkey|appkeysecret|application_key|appsecret|appspot|auth_token|authorizationToken|authsecret|aws_access|aws_access_key_id|aws_bucket|aws_key|aws_secret|aws_secret_key|aws_token|AWSSecretKey|b2_app_key|bashrc password|bintray_apikey|bintray_gpg_password|bintray_key|bintraykey|bluemix_api_key|bluemix_pass|browserstack_access_key|bucket_password|bucketeer_aws_access_key_id|bucketeer_aws_secret_access_key|built_branch_deploy_key|bx_password|cache_driver|cache_s3_secret_key|cattle_access_key|cattle_secret_key|certificate_password|ci_deploy_password|client_secret|client_zpk_secret_key|clojars_password|cloud_api_key|cloud_watch_aws_access_key|cloudant_password|cloudflare_api_key|cloudflare_auth_k |
Most application security practitioners are familiar with Unicode XSS, which typically arises from the Unicode character fullwidth-less-than-sign. It’s not a common vulnerability but does occasionally appear in applications that otherwise have good XSS protection. In this blog I describe another variant of Unicode XSS that I have identified, using combining characters. I’ve not observed this in the wild, so it’s primarily of theoretical concern. But the scenario is not entirely implausible and I’ve not otherwise seen this technique discussed, so I hope this is useful.
Lab: https://4t64ubva.xssy.uk/
A quick investigation of the lab shows that it is echoing the name parameter, and performing HTML escaping: