Banning QNetworkAccessManager

[Ben Cooksley]

On Mon, Feb 3, 2020 at 11:51 PM Johan Ouwerkerk <jm.ouwerkerk at gmail.com> wrote:
>
> On Mon, Feb 3, 2020 at 11:27 AM laurent Montel <montel at kde.org> wrote:
> >
> > Le lundi 3 février 2020, 10:49:10 CET David Edmundson a écrit :
> > > I updated:
> > >
> > > https://community.kde.org/Policies/API_to_Avoid
> > >
> > > Which had no mention of this.
> > >
> > > David
> >
> > I think that you made an error
> >
> > "networkAccessManger->setAttribute(QNetworkRequest::FollowRedirectsAttribute,
> > true); "
> > Doesn't exist it's a enum from QnetworkRequest::RedirectPolicy
> > And  FollowRedirectsAttribute is old value
> > It seems that we need to use QnetworkRequest::NoLessSafeRedirectPolicy
> > directly no ?
> >
>
> Yes, the example code is definitely wrong: in the real world redirects
> are an attack vector. A few cases to consider:
>
>  * Loops of redirects (could happen if the site is broken)
>  * Leaking sensitive information via e.g. the Referrer header

I would recommend follwoing the various browsers (Firefox & Chromium
in particular) behaviour here.
Not only are they what we generally test redirects with when doing
server maintenance, but they also have put quite a bit of work into
being secure.

With regards to loops, stopping after 10 or so redirects should be
more than sufficient as a safe guard here. 5 if you'd like to be a bit
more restrictive.
I can't imagine a need with our systems to need more than 3 (first to
https, second from somewhere to the mirror network redirector, third
to a mirror)

Because mirrors often don't support https (and Mirrorbrain doesn't
support handling https mirrors) clients that interact with
download.kde.org or files.kde.org *must* support transitioning from
https:// to http:// (under a different domain - so
https://download.kde.org to http://ftp.gwdg.de for instance). This
would primarily affected applications that need to fetch large binary
assets.

>
> Regards,
>
>  - Johan

Cheers,
Ben