While I was recently hunting on a promising host target, from my well configured (only checking SQLi) active scan results, I found out a parameter could be vulnerable to SQL injection, within the payloads:
name=' -> Redirecting to /Error.aspx page
name='' -> Redirecting to /AccessDenied.aspx page
Within further manual analysis:
name=''' -> Redirecting to /Error.aspx page
name='''' -> Redirecting to /AccessDenied.aspx page
name=''''' -> Redirecting to /Error.aspx page
name='''''' -> Redirecting to /AccessDenied.aspx page
Meaning that having singular counted single quotes broking the SQL query on the back-end and plural counted ones not broking. What a promising one!
After publishing my blog post Unauthorized Google Maps API Key Usage Cases, and Why You Need to Care and scanner script for it, I got several messages from the security researchers at the community about some inconsistency on my script results/client feedbacks and some potential API bugs related to them. Since these are started to becoming a known issue by some of the researchers, I decided to write a blog post about all the bugs that I found on the Google Maps API’s over the years - of course with the approval of the Google Trust & Safety Team.
For the %90 of my working time, I am hunting bugs on the Synack for 2 reasons:
While I prefer more to write/talk about far-going topics instead of just one vulnerability write-up, I decided to make an exception for this one because it was definitely an original one.
When looking for security vulnerabilities on a web application - either for bug hunting or a penetration test project -, I always check 2 things at last when I was clearing my testing up on a target:
The main reason for conducting these items was actually trying to find different attack endpoints especially for the attacks such as IDOR and Access/Privacy issues at first. However…
Especially when I talk with newbie security researchers/bug bounty hunters, they always make me feel as not thinking theirselves capable of finding Remote Code Execution vulnerabilities because they are super-complex. Because of this misconception, these people are actually not trying to find any of them or stop looking after some time. I think maybe the reason behind it is most of the examples/write-ups are really super complex bugs leading to the RCE from several different root causes with chaining one to another. While I am always impressed by these well-written write-ups & new ways of exploitations, I still continue to…
Most of you probably familiar within the vulnerability types “IDOR (Insecure Object Direct Reference)” and second order vulnerabilities such as “Second Order SQL Injection.”, still for the ones who are not familiar, OWASP defines IDOR in theory as:
Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files.
So if you imagine, there is an endpoint exist such as
https://ozguralp.com/my_cards.jsp?card_id=1231414 on a standard user profile, when you change
For the ones who do not have any information about this service and its API Key’s, Google Maps API is a paid service which allows applications to embed & search from the Google Maps Database and use it on their own applications. While some of the services was free at the back times of Early 2018, they changed their usage plan after that date. Since then, developers need to use an API key or client-id solution for all of the API’s they are using from.
These API keys have some security configurations for blocking unauthorized usage for malicious people which…
Independent Bug Bounty Hunter & Offensive Security Consultant