Přes 16 000 placených videí zdarma ke stažení - více než 50 TB dat 🔥 Chyby se týkaly tvůrců jako: DVTV, Oktagon, Čestmír Strakatý, Vojta Žižka, Ondřej Koběrský, U Kulatého stolu a mnoho dalších 💡Šlo získat: zveřejněná videa, videa připravená k vydání, filmy, placené dokumenty a články, mp3 rozhovory, materiály ke kurzům... Nalezené chyby byly u společnosti Tivio Studio, která spravovala pro ně obsah. Více informací na: marektoth.cz/blog/tivio-stud…

Proud to have a friend like @marektoth — DEF CON 33 speaker whose talk on Password Stealing through Browser Extension Clickjacking resonated worldwide 🌍 Great to catch up at Cyb3r Days Prague!

I disagree with these statements: ❌ "If a website has an XSS vulnerability, then clickjacking is redundant." ❌ "If a website has an XSS vulnerability, then any data leakage is the webadmin's fault." ❌ "If you only visit trusted websites, then your data in a 'vulnerable' password manager is safe." My full opinion is below ⬇️: TL;DR: • If XSS exists and I click just once, nothing happens. But if I use a vulnerable password manager and click, my credentials will be stolen. ⚠️ → My data is at greater risk if I use a vulnerable password manager than if I don't use one at all. The webadmin is not responsible for my choice to use a vulnerable password manager. • A user cannot (easily) detect Stored XSS or other vulnerabilities on a trusted website → No, this is not possible during normal use. You would have to manually analyze every script on every page. • It is not safe to visit domains/subdomains where you have saved credentials if you are using a vulnerable password manager → At the moment, on any site where you have stored credentials, you should avoid clicking anywhere at all • Can an attacker steal a user's login credentials via XSS with just one click from the victim? NO ⚠️ → They might attempt a social engineering attack (the user would have to manually enter their credentials), but the success rate of such an approach is much lower compared to exploiting a vulnerable password manager. 1️⃣ NEW LOGIN FORM Yes, an attacker could create a new login form, but that is a COMPLETELY DIFFERENT ATTACK VECTOR. This is a very common mistake and it's necessary to separate the method by which an attacker gets data and what the success rate of such an attack is. Comparison of number of interactions: - number of interactions by the victim on the vulnerable website DOM-based extension clickjacking: 1 click (anywhere) - attacker has your login credentials (9 password managers) 1 click (anywhere) - login credentials TOTP (5 password managers) 2. clicks (anywhere) - login credentials TOTP (8 password managers) ... 3 clicks - login credentials TOTP credit card 4 clicks - login credentials TOTP credit card personal data Copy/paste credentials and TOTP from password manager (e.g. KeePass): 1. Right mouse click (CTRL) 2. Select "Copy username" (B) 3. Right mouse click (CTRL) 4. Select "Paste" Username (V) 5. Right mouse click (CTRL) 6. Select "Copy password" (C) 7. Right mouse click (CTRL) 8. Select "Paste" Password (V) # 8 interactions vs 1 click 9. Right mouse click (CTRL) 10. Select "Copy TOTP" (T) 11. Right mouse click (CTRL) 12. Select Paste TOTP (V) # 12 interactions vs 1-2 clicks - and I'm not counting switching between windows What if the victim changes their mind during the process? Then the attacker will not get access to the victim account. The user decides what to enter and the form is fully visible. It depends ONLY on the user = it's a social engineering attack One click anywhere on the page and the user's credentials are stolen (the user doesn't see the form or the UI) = not user mistake, it's exploiting a vulnerability in the password manager ("social engineering" is minimal - only a single click) Result: 🔹 When exploiting clickjacking vulnerability, the attacker needs significantly fewer interactions from the victim 2️⃣ ATTACK SUCCESS RATE When will the attacker have greater attack success rate? When the user only has to click once anywhere on the page? Or when the user has to enter all their credentials into a new form? Definitely, just one click will have greater success rate. If you see a login form anywhere on a page, do you ALWAYS enter your credentials into it? What if you're already logged in, would you still enter your credentials again? What about clicking on an annoying cookie banner or login dialog, which prevents you from seeing any content on the page? Won't this happen more often? If you want to see the content, you have no choice but to click. How many times have you logged into X today? And how many times have you clicked on comments/posts/like on X? (...is X always secure? – more in part 3. An attacker can use an exploit containing all vulnerable password managers and browsers - this also significantly increases the chance of success. If I hadn't reported the vulnerabilities, we would now be talking about 12 password managers and 6 browsers (marektoth.com/blog/password-…). Yes, I'm also counting automatic autofill (0-click autofill). An attacker could have a script containing exploits for 18 password managers and steal stored credentials with 0-1 mouse click from the victim (2 clicks only for LastPass). For browsers, the limitation is only to the same domain and cannot be applied to subdomains like in password managers. 1Password, Bitwarden, Dashlane, iCloud Passwords, Enpass, Keeper, LastPass, LogMeOnce, NordPass, ProtonPass, RoboForm, Google Chrome, Mozilla Firefox, Microsoft Edge, Opera, Internet Explorer, Vivaldi I believe an attacker would have a very high success rate with stealing credentials if they found XSS on a page, don't you think? Result: 🔹 Just one click on a cookies banner will have significantly greater attack success rate than displaying a new form. With the new form the user is not forced to fill in the credentials (or is forced to, but doesn't have to do it) - An attacker can first use a clickjacking exploit and if they don't steal anything from the click, THEN they can start their social engineering attack 3️⃣ VISIT ONLY TRUSTED SITE Password manager vendors recommend "only visit trusted sites." But what does "trusted site" actually mean? Can I visit any of these sites? https://paypal[.]com/signin https://gitlab[.]com/Nyangawa/test/merge_requests/1 https://amazon[.]com/clouddrive/share/P9RHny1WRdZtZHKVnqzyXclDf6U7d2Ma9qy5Z5Y40 If you accepted cookies there, congratulations - your credentials was stolen. All of these sites have had vulnerabilities in the past: hackerone.com/reports/488147, hackerone.com/reports/508184, miro.medium.com/max/1312/0*M… But if you weren't using a vulnerable password manager, a single click wouldn't have resulted in data theft. Vulnerabilities have existed, exist, and will continue to exist. Users have the choice to decide whether to use a vulnerable password manager or not. And what about here on X? Is there really no risk for you here? I don't know the current situation, but according to the post, there was probably a web cache poisoning vulnerability on X (impact the same as stored XSS): x.com/WatcherGuru/status/190…, x.com/WatcherGuru/status/190… Just one click here on X and an attacker had your account login credentials. So what does "only visit trusted sites" actually mean? Can someone from the password manager vendors teach me how to detect such a site? Result: 🔹 It is not easy to detect whether a trusted website has an exploitable vulnerability - No, it is not possible during normal use. You would have to analyze every script on every page. 🔹 You cannot safely visit domains/subdomains where you have stored data if you are using a vulnerable password manager. - Currently, on all sites where you have stored data, you shouldn’t click anywhere at all. 🔹 If you are not using a vulnerable password manager, a single click will not allow an attacker to obtain your data. 4️⃣ IMPACT WITH XSS I very often read that an attacker can do this and that with XSS. Ok, important question: Can an attacker steal a user's credentials in plaintext with a single click via XSS? NO An attacker could steal a session using XSS… Yes, maybe a few years ago. But today, it's not that simple - especially on widely used websites. Most modern frameworks automatically set the HttpOnly flag on session cookies, which means sessions cannot be stolen via javascript (=XSS). Even if it were possible, a session is not the same as credentials. With credentials, an attacker can create a completely new session, which won't be invalidated when the user logs out. Autofill on subdomains: All password managers that I tested in research fill credentials not only on the "main" domain but also across all subdomains. For example, if credentials are saved for x.com, they may also autofill on test.x.com, dev1.subdomain.x.com etc. Now, let's say there's an XSS vulnerability on dev1.subdomain.x.com. What's the actual impact? Almost none! The main domain and its core functionality are on x.com. Any attempt to make a request from dev1.subdomain.x.com to x.com will be blocked by the Same Origin Policy (en.wikipedia.org/wiki/Same-o…). So, the session cannot be stolen, no request is sent, and no data is obtained. However, if you use a password manager that is vulnerable to clickjacking, a single click is enough for an attacker to get your credentials. This is precisely the major problem when credentials are autofilled across all subdomains. Example with 1Password: On the bug bounty platform HackerOne, they have the domain support.1password.com listed as "Out of Scope" (hackerone.com/1password/poli…). No ethical hacker will look for bugs there, so there could be many vulnerabilities with no one motivated to find them. And what about a "non-ethical" hacker? If they find an XSS vulnerability there and send you an email with a link to support.1password.com, what happens if you click it once? The attacker could steal your credentials stored for my.1password.com - your email and password for your vault (but not your secret key). Result: 🔹 Autofilling credentials across all subdomains significantly increases the risk of abuse. The attacker has a large scope for finding vulnerabilities. 5️⃣ BLIND XSS AND CLICKJACKING Blind XSS is a type of XSS where the script executes on a completely different page that is hidden from the attacker. For example, an attacker injects XSS into a review on an e-commerce site (e.g., amazon.com). The script does not execute on the public-facing site, but it executes later in the administration when an employee accesses it (e.g., admin.employee.amazon.com). Did the employee visit a malicious site? NO They were simply using their administration panel as usual. One click, and the attacker could steal their credentials. And these credentials don't have to be limited to administration panel. They could also be used, for example, for the employee's email. Why can't the attacker just export more data immediately? They can't, because they don't know the structure of the web application. Which requests should they send? Yes, they can immediately get the content of the current page - but that might be limited to, for example, a list of reviews, and not sensitive information. Theoretically, their script would have to collect all URLs and send requests to them repeatedly, and so on. But we are still only talking about the impact of the XSS vulnerability. Can an attacker obtain stored credentials with just one click from the victim using only XSS? NO However, if the employee us using a vulnerable password manager, then YES. Result: 🔹 An attacker can exploit a vulnerability (blind XSS) along with clickjacking to obtain employee login credentials. - Without clickjacking, the attacker would not be able to easily obtain the credentials and would need to rely on a social engineering attack. -------- And this is what companies often label as an "acceptable risk". I looked around but couldn't find any similar explanation of security risks from companies that still have these vulnerabilities, leaving most users unaware. If you've read all the way to this point, I truly appreciate it 👍 If you agree, I would be grateful if you could share this to help it reach a wider audience. Thank you 🙌

DOM-based Extension Clickjacking UPDATE (24.8.): FAQ: An attacker can create a new login form using XSS, so why would they use clickjacking❓ My answer: github.com/keepassxreboot/ke… Bitwarden: latest version (2025.8.1) still vulnerable ⚠️ Demo sites: websecurity.dev/password-man… LogMeOnce: New release - I am waiting to be added to Chrome Web Store support.logmeonce.com/hc/en-…

New update to the "DOM-based Extension Clickjacking" research 🔐 Bitwarden: 2025.8.1 (in progress), <=2025.8.0 (vulnerable) ⚠️ Enpass: 6.11.6 (fixed) ✅ KeePassXC-Browser <=1.9.9.2 (latest) is vulnerable ⚠️ New demo sites for: 1Password, Bitwarden, iCloud Passwords, KeePassXC-Browser, LastPass New videos with all currently vulnerable password managers marektoth.com/blog/dom-based…

[CZ níže👇] Newly described clickjacking technique "DOM-based Extension Clickjacking". I tested it on 11 password managers and all of them were vulnerable. 💳 1 click and the attacker has your credit card details 🔥 Currently still vulnerable: Bitwarden, 1Password, iCloud Passwords, Enpass, LastPass, LogMeOnce 👉 Full research: marektoth.com/blog/dom-based… ------ CZ: Nově popsaná clickjacking technika "DOM-based Extension Clickjacking" Testoval jsem ji na 11 správcích hesel a všichni byli zranitelní 💳 1 kliknutí a útočník zná údaje k vaší platební kartě 🔥 Stále jsou zranitelní: Bitwarden, 1Password, iCloud Passwords, Enpass, LastPass, LogMeOnce 👉 Celý research (CZ): marektoth.cz/blog/dom-based-…

Na Herohero jsem našel kritickou bezpečnostní chybu Šlo se přihlásit na libovolného uživatele - stačilo jen znát URL profilu💀 Všichni tvůrci byli v ohrožení. A nejenom oni, také i ostatní uživatelé. Šlo krást peníze z platební karty - BEZ POTVRZENÍ🤯 marektoth.cz/blog/herohero-k…

Jedna vteřina a útočník mohl mít neomezený přístup do vašeho e-mailu. Stačilo pouze to, abyste používali stránky Seznamu. O co šlo? Prostě jste jen používali stránky Seznamu a nebo klikli na odkaz. Vše se dělo na pozadí, aniž byste to mohli ovlivnit. marektoth.cz/blog/dalsi-krad…

V roce 2020 jsem nalezl na portále Seznam_cz chybu, která vedla ke krádeži uživatelské session, a tím šlo získat přístup do cizího emailu. Ke krádeži stačilo pouze to, aby byla oběť přihlášena k emailu a otevřela stránku, ve které byl útočníkův kód. youtube.com/watch?v=zCsKX-19…

Stále se píše o phishingu, ransomwaru a podobných typech, ale internet je mnohem nebezpečnější 💀 Momentálně vydávám úvodní video, kde se představuju. To vše, abyste věděli jak přijímat odborné informace, o kterých budu v budoucnu mluvit. youtube.com/watch?v=NuePuMD-…

Newly added FAQ section where I explain the most common questions. marektoth.com/blog/password-…

I'm sorry to everyone who wanted to try website with XSS exploiting autofill - websecurity.dev. The hosting blocked POST requests from abroad. It is fixed now.

Topic about password managers is very popular in IT security. However, very often, there is no mention that you should turn off autofill. In the following analysis, I have described the risks associated with the use of this feature. marektoth.com/blog/password-… @LastPass @dashlane

Správci hesel jsou v dnešní době velice oblíbeným tématem. Často ale není zmíněna informace, že byste si měli vypnout automatické vyplňování. Rizika spojená s používáním této funkce jsem snažil popsat v následující analýze. marektoth.cz/blog/spravci-he… @stickypassword

We have combined all the tricks we know about SSRF into a single mindmap. If we missed something, write about it in the comments! High resolution: raw.githubusercontent.com/ha… XMind source: github.com/hackerscrolls/Sec… #CyberSecurity #BugBountyTip #BugBounty

Na Seznamu jsem nalezl bezpečnostní chybu, která umožňovala ukrást cookies přihlášeného uživatele, a tím šlo získat přístup do cizího e-mailu. Stačilo pouze to, aby byla oběť přihlášena k e-mailu a otevřela libovolnou stránku, ve které byl útočníkův kód. marektoth.cz/blog/kradez-coo…

Používáte Shoptet, Eshop-rychle, Webareal nebo UPgates pro váš e-shop? V posledních měsících jsem provedl základnější bezpečnostní test a výsledkem bylo, že více než 34 000 e-shopů mělo závažnější zranitelnost. marektoth.cz/blog/ceska-esho… #ecommerce