4.2 KiB
CHAT Dar about using UI Components in the login pages work chat
[2021-12-21 Tue 10:20]
@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?
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.
- I need to create a notion of session when the user is logged in in the IdP but has not selected a SecureX account.
- 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:
url:http://attack.com/foo?param=something-complex
foo@example.com
some random text
carriage return, unicode, emojis? etc…
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.