Potential way to highjack the auth header ?

[marvin-enthus]

Hi,

by developing the PR in #157 we tried to think whether this will introduce a security problem. During the discussion we noticed the authorization header will be added to every url - to any host.

So what happens when I send a link https://dbsystel.github.io/trivy-vulnerability-explorer/?url=<my-evil-site-where-i-capture-the-auth-headers> to a browser with saved authorization headers? Havn't tried yet but from the code it could work...

A solution might be to also configure a server or domain name for the authorization header - and only add the header when the host / domain of the url matches the configuration.

It might be i'm missed something - then just drop this issue. When this is real - sorry for the bad timing :-/

Bye,
Chris

[Morl99]

Hello Chris,

you are right, it would be possible to steal the credentials that way. An easy fix would indeed be, to also add a domain, I am a little worried that this needs to be a breaking change though. It might make sense to make this an optional field as first, so that users who have the credentials setup will not be disturbed.

The attack is a phishing attack of some sort, so I am not wildly concerned, as I think that most users of the software should be tech savyy enough to avoid clicking on a link like this if it is not expected. Nonetheless, preventing this kind of attack for the future is a good idea.

[marvin-enthus]

Hi,

just a few brief thougths:

• As you are concered about disturbing the current workflow: In my other ticket I mentioned the idea to popup the configuration window when there is no local configuration. Maybe this would also be a smart way to migrate it for existing users: When there is the header configured, the server path is extracted from the url parameter and filled in as default. So the user just has a on-time 'OK' click to confirm the new server & settings and is fine again.
• Maybe it would be an idea to allow different configurations for different servers - so there could be server a with its auth header, server b with an other auth header and server c with includeCredentials enabled.

What do you think? I don't expect the 2nd option is something we both require, but maybe it could be a thing for some other adopter ;)

Bye,
Chris