Hi,

I am Marek Tóth and I'm interested in IT security, mainly focusing on finding security vulnerabilities in web applications. I have been actively interested in this area since 2018.

In my free time, I try to make the Internet a little more secure place and look for web vulnerabilities that could be exploited. Vulnerabilities that I found, I report via bug bounty program or I send them directly to a specific company.

Work experience

03/2020 - Present Penetration Tester (Ethical Hacker), Avast
01/2019 - 02/2020 QA Engineer, Avast
03/2017 - 10/2018 QA Engineer, Mall
10/2016 - 02/2017 Software Tester, Tipsport
07/2015 - 09/2016 Customer & Technical Support, Tipsport

Public Talks

You should turn off autofill in your password manager
05/08/2021, OWASP Czech Chapter Meeting

Explained the risks of using autofill in the password manager (blog)
- 9 of 16 browsers and password managers had automatic autofill enabled by default
- in total 11 of 16 browsers and password managers were possible to steal a saved password within one mouse click

Presented in English

Security testing of Czech e-commerce platforms & Cookies stealing on Seznam.cz
01/12/2020, OWASP Czech Chapter Meeting

Security testing of Czech e-commerce platforms (blog)
- 34 500 e-shops had vulnerabilities leads to database stealing or e-shop takeover

Cookies stealing on Seznam.cz (blog)
- all users were potentially at risk, around 8 million active email accounts
- an attacker gained access to the victim's email if the logged-in user opened a website containing the attacker's javascript code

Presented in English - online

Workshops

Tips and tricks for testing web applications
08/11/2020, Digital academy: Testing, Czechitas

Focused on common developer bugs and missing test cases of testers
Issues shown on production websites Alza.cz, Aboutyou.cz and Mall.cz
During the workshop a security/business bug was found on https://moje.czechitas.cz (changelog)

Wrote about me

Pronajímané e-shopy většinou nejsou bezpečné. Zranitelných bylo 34 500 - Seznam Zprávy
Seznam měl vážnou chybu ve svém e-mailu. Útočník se mohl dostat do schránek uživatelů - Živě.cz
Seznam měl vážnou zranitelnost, šlo se dostat do e-mailů uživatelů - Lupa.cz
Seznam umožňoval únos sezení - Instaluj.cz
Seznam.cz byl děravý, bylo možné ukrást účet. Tím i přístup do e-mailu a k dalším službám - rychlofky.cz

The path to IT security

I have been interested in IT security since I was a kid, at that time I didn't understand it at all and I was just a script kiddie. For example, back in primary school I found SQL injection in the login form on the school website, but I had no idea how it worked - I just tried something I found on the internet. While working in customer support, I tried to look for security vulnerabilities, but I kept running into ignorance in the field. I was either finding small security flaws (the "highlight" of my knowledge at that time was Clickjacking 🙂 ) or I was just finding user vulnerabilities, which led me to the position of a tester.

Initially, I paid attention to my new IT position, trying to find as many developer bugs as possible, but something kept bothering me. It bothered me that often the bugs I reported didn't have a significant impact on users or the company. It took a change, and in the spring of 2018, I started more actively seeking information about security testing. After a few months of self-study, the first more interesting results started to come in.

Since 2019, I have been interested in the field of web application security on a daily basis, with the addition that I also started bug bounty programs in that year. First it was Hacktrophy, later it was Hackerone. From my point of view, the experience of bug bounty programs is the biggest asset for a tester. Not only does he get hands-on experience of different web applications, but he is also forced to think about the risk of the vulnerability found and the combination increasing the overall impact... because no significant impact, no money 💰

Finding vulnerabilities

As I mentioned before, my practical beginnings were on the bug bounty platform Hacktrophy. For example, the pricing from one bug bounty program I worked with for a few weeks looked like this. To this day, I still draw from that experience and still have it embedded that unless it is a vulnerability with significant impact, it is not worth writing down. In the case of my current job, of course, I can't stick to that, but when it comes to reporting to external companies in bug bounty or vulnerability disclosure program, I always try to report only vulnerabilities with a larger impact.

For web applications, I'm currently focusing mainly on finding client-side vulnerabilities, with my target being Account Takeover, Session Hijacking, Permanent Cookies Stealing, AuthToken Stealing, so I'm targeting vulnerabilities that allow absolute or limited control over the account. Since these are client-side vulnerabilities, interaction from the user is required, so I always aim for my result to be a maximum of a link without any further action from the user - just by opening the link I am requesting a lot from the user.🙂

I always try to look for vulnerabilities that are harder to detect and could primarily be used against people in IT. If it worked on them, I would be confident that the attack would work on non-IT people as well. It would be easier with a reverse approach, but it wouldn't be as applicable. So I often follow the rule: If the attack technique used would not work on me, I don't pursue it further and think of another way. If I write it differently - I am very impact-oriented. If an attack works on 10 people out of 1,000, I don't focus on that method and focus on a technique that would work on the remaining 990 people. At the very least, the vulnerability I find should be functional for more than 50% of all users of a web application.🙂