Get a security evaluation today !
Contact Us

Privilege/Restriction Overriding on Google Data Studio

Well, if you have grown up, do you still remember the ‘Do’s & Dont’s’ in your childhood days? Yes, we don’t actually forget things that go right and wrong in our younger ages. But how far have you taken the validity? Possibly until you have got enough knowledge to judge those and make decisions on your own. Mistakes can happen anytime while making decisions, and it’s a part of brain activity where it feels to rest a bit.

Google has made our lives simpler and pretty easier in terms of digital aid. While living in a world of technological advancements, the world has reduced to zero time delays with Google functionalities and features. One such important feature tool from Google is the Data Studio. As we mentioned earlier, every developed functionality is a converged process of multiple brains, and bugs can be a part of the enormity.

The tech blog bridged to Google Data Studio pinpoints a bug identified by Mr Hariharan S, Security Analyst of ValueMentor, with his out of box reasoning capabilities and skilled interpretations. He is one of our expert Cyber Security Analyst, who go beyond expectations at every bit of his journey. But before diving into the bug, let’s first understand Google Data Studio and the privileges or restrictions encircling the users.

What exactly is a Google Data Studio?

Introduced by Google on March 15 2016, Google Data Studio is a free online tool that turns the supplied information or data into customizable information reports and dashboards. It helps to convert your data to appealing and informative reports in no time. The online tool is a part of the enterprise Google Analytics 360 suite, and free versions are readily available for use. Various benefits of using the Google Analytics tool includes;

-Unlimited widget options

-Converge data from multiple sources

-Create and share easy to read reports

-Dynamic reporting and free templates

-Supporting data studio tutorials

When the glitch caught his eye

It was amidst the usual survey on the working of the website and its functions where the digital tick paused for Hariharan. There were two privilege/restriction options within the report sharing feature that attracted the inspection.

Before jumping with the wave, he gathered the required functionality of the options, their implications and detailed working. Having the security testing blood within, he decided to test the functionalities and see if he could bypass the restriction or privilege from the viewer side.

Explaining the restriction option

As mentioned earlier, there were two privilege controls or options while creating a report. The entire focus shifted to the second privilege, ‘Disable printing, downloading and copying for viewers’. The functionality is as follows,

*If the privilege option of ‘Disable printing, downloading and copying for viewers’ gets unchecked or not turned on, a report duplicate can be made from the viewer side. When the viewers click on the option, a request gets passed to create the report copy.


*If the privilege option of ‘Disable printing, downloading and copying for viewers’ gets checked or turned on, then the option to create a report copy is disabled on the viewer side. It implies no request gets passed in this case.

Into the creeping bug

Here is where the out of box instinct of Hariharan raised to the picture. His idea was to create a report copy from the viewer end when the privilege option or restriction is turned on.

First thing first! He created a report for the test case and captured the request of ‘create a copy of the report option’.

POST u/0/copyReport/Report ID

And the next thing, he turned on the restriction that is ‘Disable printing, downloading and copying for viewers’ for the report and replayed the same request on the viewer end.

Proving his assumptions and instincts right, he surpassed the restriction and made a copy of the report. He could do it because there was no validation for the requests on the server side.

The issue was reported to Google and fixed on the below timeline.

Recorded Timeline

Issue Reported: Feb 5, 2020

Triaged as P2: Feb 7, 2020

Nice Catch: Feb 10, 2020

Accepted → Fixed: Feb 20, 2020

Why do we need Server-Side Validations?

As web applications and features are on the exponential rise, keeping pace with fast-growing demands, input validations go significant and an inevitable factor to compromise. There are two forms of validations as a security measure- the former, client-side and the later server-side. In the digital era of security implications, user input validations and sanitizations are necessary and an integral part to check and consider.

Client-side validations produce a smoother experience, but server-side validations ensure that any client-side restrictions bypassed gets validated again before reflecting it to the user. It is a defence line for inspecting requests against advanced business logic and malicious interactions. Client-side validation is never bulletproof proof, and any validations here doesn’t promise a zero compromise on the server end.

Wrapping Up

The tech blog is a hall of fame success finding by Hariharan S (Security Analyst at ValueMentor), which is an added feather to our expertise and exposure in the cyber domain. It is an exploring and out of box call which matched glory and recognition to the finding with tested evidence. The other reflected perspective is that sticking to your instincts can be fruitful if you have the skill and confidence to surpass the same. It is always not normal to settle, and one must keep the flow to learn and unlearn different things.



Related Posts

View all
  • December 20, 2022
  • December 16, 2022
  • December 15, 2022