deft/tracker.tmp8YFKFI.org
Yann Esposito (Yogsototh) b3002547e9
tracker.tmp8YFKFI.org
2021-12-21 12:03:13 +01:00

108 lines
4.2 KiB
Org Mode

# Created 2021-12-21 Tue 12:03
#+title:
#+author: Yann Esposito
* CHAT Dar about using UI Components in the login pages :work:chat:
[2021-12-21 Tue 10:20]
#+begin_quote
@Dar
Hey Yann, a question came up in our weekly sync about the login flows…
now that they're getting a bit more sophisticated wouldn't it be better to
start using common UI components rather than taking snapshots/hard-copies
of styles and generating one-off templates?
what are the security concerns around client-side rendering the auth UI?
#+end_quote
Hi Dar,
So to answer the question historically.
First, we didn't have any login page.
It was 100% hosted in CTR UI.
I just provided the route to create the login links (and this could still
be used today and it is in the new login page).
We faced many bugs (most of them related to URL encoding), and thus decided
to close the gap by building an hosted login page.
That way I can 100% control the behavior and have lot of tests to check url
encoding related bugs.
Do not forget that in CTR you often want to deal with URL with very complex
URL fragments that contain a representation of the investigation, imagine
text with carriage return, URL, emails, etc…
Even recently we experienced subtle bugs. And the solution was to get rid
as much as possible of the javascript code that handled the url parsing and building.
Now, this is handled via the backend on the login page.
So the 1st reason to host the login page was convenience and bug fixing and
not necessarily security.
Regarding security, I was afraid to introduce a security bug because, the
login page is clearly a nice entry point for security attack.
So I tried to be as conservative as possible.
So no js when possible.
And if we need to use js, do not use any lib, just basic javascript so the
code is easy to understand and debug.
There is another complexity to keep in mind.
For historical reason, for now, there is no "session" when the user has
logged in via the IdP but hasn't yet selected a user and thus is not logged
in SecureX.
Right now, we handle this state with a token in the URLs.
And this token can be consumed only once.
By that I mean, in the account selection page you will have links looking like:
- https://..../select-org-1?code=XXX
- https://..../select-org-2?code=XXX
- https://..../select-org-3?code=XXX
When the user will click on the first link; the code =XXX=
will be consumed and the other links will not work.
So I ensure that the user need to perform a login workflow again to login
into another org.
So that being, said.
I think now we are in a new situation where I think we could totally have a
lot more convenient system.
1. I need to create a notion of session when the user is logged in in the
IdP but has not selected a SecureX account.
2. Use more js to ease the UI work, typically, UI components. The limit
being that the CSP header are restrictive in the sense that we must host
the JS at the same URL, and we should probably still generate data via
the backend, maybe still keep a bit of HTML.
In fact, we need the backend to be able to provide a set of informations to
the UI and take care that no XSS could be possible.
I think the main risk is that, the login page must support complex query
parameters.
So great care should be taken in the parsing of these query parameters.
To give a concrete example:
You should be able to generate a page for a URL looking like:
https://securex...cisco.com/login?redirects=<URL2>
Where URL2 should be encoded correctly, and could itself be complex:
URL2: https://visibility...cisco.com/investigate#q=<QUERY>
Where QUERY should be encoded an could contain urls, emails:
QUERY:
#+begin_src
url:http://attack.com/foo?param=something-complex
foo@example.com
some random text
carriage return, unicode, emojis? etc…
#+end_src
So to present the login page, every button should take care that adding a
=<script>= somewhere will not generate an XSS, that the encoding is correct.
And that login link could be forged by an attacker, and it should not be
possible to hijack the redirection to a non allowed login endpoint.
Because in that case, the endpoint will get a =code= from which we could
retrieve the creds of the user.
To me this totally doable, and I think should be the preferred route.