108 lines
4.2 KiB
Org Mode
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.
|