Mark Alan Richards

Data Access Tests

security privacy data-protection

Are websites too trusting?

Once upon a time, Mixpanel analytics slurped up input values from form fields.

A "bug" in their code resulted in them collecting data, including in some cases usernames and passwords.

There was no hope for average Joe to spot this.

There was not much hope for most web developers either... as Mixpanel's code slurped up the values and base64 encoded them, before then submitting them to their servers.

Unless web developers find time to decode payloads being sent to JS integrations, this isn't something they would have spotted when monitoring their app.

Mixpanel analytics accidentally slurped up passwords

That was 2018 and now we're in 2023, we should be safe?

Data protection laws have improved dramatically over the last years and companies should be in a much better position.

As not only do the laws typically defend against inappropriate processing and collection, they also require companies to put in place appropriate access controls.

Can you justify why an unnecessary analytics system should have "access" to credentials?

So, let's test this

I apologise in advance for my JS, this was put together quickly.

https://gitlab.com/markalanrichards/access-test/

We can use a web testing framework to proxy third party JavaScript.

Where there is third party JS, we can amend it by appending some code.

Integrity Check

Let's append code that just adds another script tag to the body, but this time with a secret query parameter we can spot in our proxy to see if the code successfully executed.

If we receive a response, then there's no SRI check and the third party integration has programmatic access to the website beyond the access control of the site origin.

Input field collection

We can also append more JavaScript that adds more script requests back to the same server, but embed in input field values in the requests.

Then, if our test suite populates usernames, passwords, card numbers, etc then if the integrity check didn't work, we'll probably see them too.

Not all of the examples here include tests for input fields, so any absence in the report does not indicate it cannot be done.

Notably, if a script has programmatic access to a home page, what is to top it adding it's own login form to capture your details?

(CSP may have features here and if anyone wishes to help me test that please get in touch)

An example config file to run the tests

https://gitlab.com/markalanrichards/access-test/-/raw/main/example.yaml?ref_type=heads

Example test report

This is an access test report

This is not an exhaustive access test, there may be JS files that have been missed

There are some attempts below to check for whether form values can be read on login pages.

JavaScript without limitations may be able to spoof a login form on any page and collect data there too, so often where there is no JS integrity there are security risks.

Report: