Micro Frontends and Security

Hi, everyone, and welcome to the session about micro-frontends and security. I hope you had a great conference so far, and I hope to also bring you now some insights into developing your micro-frontend solution with security in mind.

Before we start, just a few words about my person. I am Florian, or in short, just Flo. I'm a solution architect working for a smaller company here in the Munich area in Germany. We are specialized in the creation of IoT platforms and distributed web applications in general. We are also doing some workshops and reviews. So if you have, let's say, any kind of demand in those areas, want some general consulting or thinking about going into micro-frontends, then always feel free to ping me or shoot me a message on LinkedIn. Now, enough words about me. Just jump in right into the topic.

And one thing that I always like, of course, to show, and this will be, let's say, the guide also for today's session, is to have a look at the OWASP top 10. So this is a list of the most, let's say, critical and most used security vulnerabilities in the sector of web applications. And they make an update of this list fairly regularly. And what you can see here is the most recent list out there. And I brought four topics from this list where we can, let's say, identify what usually goes wrong in micro-frontend solutions and what we can do to mitigate those vulnerabilities and attack vectors that you naturally occur.

So let's kick it off right now with the third one, which is injections. So micro-frontend systems are quite often very open for injection attacks because this is what micro-frontends are all about. We are injecting code that is, let's say, not directly at build time composed together, but will be composed together at runtime. Very naturally, you will have to face injection attacks or attack vectors that you need to mitigate for. And we will have a look at that.

The other area is to look at insecure design because very often, of course, you open up with these, let's say, kind of runtime compositions to insecure design, meaning that you suddenly allow maybe others to have their code running, which at first seems fine. But how can you ensure that the code that was published by someone now is really the code that was published by this, yeah, hopefully trusted person? And very similar, but of course, slightly different, is security misconfiguration. So here we deal in an area where we say, how can we configure the system in such a way that even though we needed to open the door in some areas, it's not as widely open as, well, potentially can be such that, for instance, maybe the middle attacks can occur, or that there can be some modifications on the way from, let's say, a server to the user's browser, for instance.

And what I want to start with, and that will be the first area that we look at, is essentially, well, the good old identification and authentication flaws. So how can you ensure that you authenticate your users, and these are really the users that we want to have, want to see, plus, of course, the data, potentially, let's say, tokens, for instance, are not lost, or get, well, into the hands of somebody that you don't want to share the token. So let's have a look there, and let's start with the authentication flaws.

The tech vector that I brought for today's talk, we only have 20 minutes, so I need to be fast, is that we use token-based authentication. There are more tech vectors, but I will, all of these sections that we just covered, only mention one tech vector for each. Now, for the tech vector that I selected here, token-based authentication is very popular, right? If you create a single-page application, then potentially you use a mechanism like OAuth2 with a JWT, which is a token that is usually stateless, so you can just transport it. And the good thing is that it can just be created from one system, but multiple systems can read it and can verify that this is indeed a user that was properly authenticated by this one system that created.

So, if we look at that in a diagrammatic point of view, what you see here, we have our site that's in the blue rectangle and then, of course, we are running three micro-frontends in their orange, purple, and green. And what you see is that, well, orange and green are all good. They're sending the JWT to their respective APIs, but purple is not sending it to the purple API, but to some malicious site here. Now, the malicious site is, let's say, the ownership of that JWT. And that's not really what we want to have. So, what can we do here? How can we mitigate that? Well, there are various things to do, but I always like to point out one of the simplest solutions, and in my opinion, here it is, to just do session cookies. Especially if you set, of course, the policy to the same site, what you should do. So, you constrain this. Another thing that you should do here is to have them HTTP only and all the secure HTTP channels. Then you're really, let's say, well off. So, the cookies only exchange the same domain under the circumstance that it is not, let's say, visible within your JavaScript code. And it is only, let's say, exchanged when you have a secure channel open. So, everything is great then and you don't need to have the authentication token. You don't need to distribute them among your micro-frontends. The browser will always do the right thing automatically. So, quite good. We are all set here. And if you look at how the diagram changes, you now see there is this gateway that's now between the website that's running and the respective backend APIs. And the job of this gateway that we introduced here is twofold.

So, quite good. We are all set here. And if you look at how the diagram changes, you now see there is this gateway that's now between the website that's running and the respective backend APIs. And the job of this gateway that we introduced here is twofold. On the one hand, it is, of course, the keeper of the sessions. So, it receives the sessions and then, of course, can do something with these sessions. For instance, exchange the session to a JWT. And the second thing is it then proxies the request to some target destination. So, it's generally a reverse proxy and it takes paths that it doesn't, let's say, resolve directly to. But it then proxies, of course, it detects what the target is. That it should be, of course, a target that we configured previously. And then it just forwards the respective JWT with the rest of the request details to the target. So, quite nice. And if you now would go to a malicious site, I mean, nothing would happen because, well, the cookie isn't sent here. And, yeah, you don't care, essentially. You still shouldn't go there. But, I mean, the attack vector is mitigated. Great.

Now, in Codeform, what we could see here is that we had a fetch beforehand and this other service mycompany.com. Well, now we just go to API slash other service, and now the gateway would know that, for instance, the end request should be dispatched to other service of mycompany.com. But the important part, again, is that we don't mention here a domain because it should go to the same origin. So, the domain is implicit in this fetch. And we don't need to have, now, this token. So, we also don't need to take care of, for instance, a token refresh. So, all in all, our frontend is now a little bit simpler than before and also more secure. I would say it's always quite a win.

Talking about, of course, having a secure frontend, insecure design is the next problem that might occur, right? So, how can we ensure that there is, well, at least no man-in-the-middle attack from, let's say, the source where we store our micro frontend to the browser? Now, there are various reasons why this might occur, right? It might not even occur on, let's say, transportation channel between, let's say, the storage point of the micro frontend and the browser. But it could even occur that the storage, let's say, itself is insecure. So, I don't know, someone lost the password for, let's say, an Azure Blob Storage and you locate your micro frontend there. Now, of course, if that access key to the Azure Blob Storage falls into the wrong hands, the content might be changed.

But there is one way or there are multiple ways, again, to mitigate for a scenario, as it is outlined here, where you say, oh, now instead of getting the purple micro frontend or original purple one, we get this modified JavaScript code. So, the two ways to do it, and I'd like to talk more about the latter here, is to have code signing, which means you use an approach that's very similar to a JWT. You, let's say, have a public and a private key, and through the private key, you can, let's say, together with, for instance, the hash, put something in your code that says, well, if this is fulfilled, the code is properly signed, so you can read it out later, the code itself is still totally readable, and together with the public key, you verify that this hasn't been tampered with. But there's also a simpler way, so, of course, that makes some assumptions as well, and that is just to transport the integrity of the JavaScript file, and this is essentially just the hash function used on the binary contents of the file. Now, if we get, for instance, together with the reference that we usually have to a microphone, this integrity, so the hash, then we can, of course, use it to also verify that the content hasn't been tampered. How that works is that you usually have a central microphone discovery service, and you place this in the middle of your architecture, such that your application does not only, let's say, get the references to the JavaScript, but also gets these integrity values, and then you can instruct the browser to actually use the integrity values, and ensure, therefore, that only if they haven't been tampered with, they will be run. So, quite nice, and the browser will, in this case, block the modified JavaScript because it sees there's a mismatch between what the discovery service said, what was originally uploaded, of course, and what we actually received. And again, it doesn't matter if we received it because there's a problem with the transportation channel, or because someone could tamper with the storage of the files. And for us, it's a good thing. In code form, it might look like this. So, the first part is the response from a discovery service. It tells us the name of the microphone, the version, it also gives us, of course, a reference to it, and then, importantly, gives us the value for the integrity. Finally, if we want now to embed this, we will put it in a script tag, and this wouldn't be hard wired as we see it right here. Of course, this is all done programmatically, but the really critical part is that we use the integrity attribute that is already, let's say, understood from all evergreen browsers, and we are fine. The browser will not block the execution of this file if it detects that the integrity is not fulfilled. Very well, so, another problem has been solved. This is great. There are just so and so many left, but let's look at the problems one at a time, and let's continue with injection, right? As already mentioned, injection is something that you want to have, but you want to restrict it as much as possible, following, of course, the principle of least privilege, that you don't open it unnecessarily wide, but only as far as you need to open it. Now, the attack vector that we see on this aspect is, well, of course, we can construct an attack vector in the browser, but maybe let's shift a little bit here and say we run microformance on the server. Now, here, of course, we have quite some critical attack vectors happening very naturally because, well, everything runs in our, for instance, server, so we might have access there to some SQL database. We might access here to a Redis cache or whatnot. So, many, many resources, the environment variables, which are usually used and, for instance, get the access to something like the SQL database, they are very, very sensitive. So, at the end of the day, what we could say, if there is some code injected, which, for instance, can then read environment variables, could also send it somewhere. Now, we could still argue, maybe we can follow a model like DNO and restrict unwanted HTTP requests, but let's say we are Node.js, we don't have such options. Sure, we could still shield the service, but then there are plenty of other vectors here. So, how can we prevent this in the first place? The answer in Node.js is that we can sandbox using the VM module. Essentially, this allows us to really just determine what things should be accessible from a module when we run it. This is great because then, of course, resources like, for instance, accessing fetch or accessing some third-party dependency that can have access to fetch can be severely restricted, and you don't need to care about any of those. Even better, you can restrict from the beginning on. You don't even need to have access, for instance, to process EMV.

You can just supply your own environment variables just for the evaluation of this module. So, if you look at an example here, and this is just really a simple, simple, simple example what you can do, but to show it is that we use from the VM module to create context and run in context, create context, to create a new evaluation context. We throw in everything that the module needs to know, basic general things like finding deal name, but then, of course, maybe also JavaScript fundamentals like buffer, JSON, et cetera. And then the respective part where it gets interesting is process and require, right? Because the process itself, so this thing has really some, well, let's say implication on what you could, well, know in your module. So, you should at least provide something here, but you should, of course, restrict something like process EMV. So, what we see here, this could be a good starting point, but I would advise not to just pass in all the process EMV variables. So, this is just, let's say, maybe a little bit of an anti-pattern example. And the other thing is, of course, having the API fully done and the custom require, we don't go in details here, but potentially you want to allow using certain things, but in general, you don't want to have, let's say, maybe require anything in there because that could be used to, of course, get into maybe unwanted territory again. And finally, if you're running context, interesting part is you can set a timeout that, well, you essentially limit your, how long a script may run. And that's also good because you don't want a rogue scripts to stall your server.

Last section that I want to talk about is misconfiguration in general. Here, the general advice that I want to tell you upfront is always try to use as much of the web standards as possible. So, if you know, there is a certain thing, like let's take course. I'm not talking about course today, but you should not try to avoid it. You should embrace it and you should rather think, how can I use my course to fit into my micro-format solution and to still open the door as much as it should be possible, but not, well, as much as it is needed, but not as much as possible. All right. So, let's try to wrap this up. The attack vector that I see here is a third-party script that we, of course, have plenty of. We usually have a lot of dependencies and such a script could contain, for instance, a key logger, right? I mean, you don't know how they are always NPM packages that have gone rogue. And there's always a little bit of delay until the community finds out that there is something really bad happening here. And so, this could be something that you run into. You just update your dependencies and suddenly we have a rogue script in there. So, it's not even that we are claiming that the teams are making a mistake. Well, I mean, of course, they are, but they're not really knowingly making this mistake. Now, the question is, how could we, let's say, intervene here? What can we do? And, well, the first thing that I would like to talk about, but there's a second thing that I want to introduce, is to include a content security policy, because that limits the execution of just arbitrary code. And while certain things may still be possible, other things will be really, well, crippled or not be possible at all. Now, how a CSP works is quite simply explained when the browser sends a request to the server and the server responds to it and it can attach various, let's say, headers. And one of these headers is a CSP policy that can be added. You can do a little bit more, like include a report service.

You can do a little bit more, like include a report service. So, not, let's say, have violations be treated as errors, but rather as warnings. These warnings could be sent to a URL. So, the whole bottom section of this diagram here is, let's say, for convenience or let's call it flexibility. But the upper part, this is really interesting because here we can configure the browser and how it interprets access to resources. And it does that via this header, as mentioned. This header then consists in the value of different so-called policies. So, everything in such a section between the semicolons, that's a so-called policy. We have a default policy. So, what do we assume as a default source? So, self is always default. So, that's fine. Then if it's coming from the same origin images, for instance, we allow everything. That might be dubious, but it's just as an example here. For media sources like audio, video, we have some domains allowed and the scripts we only allow from the main user scripts example. So, now we defined our policies and the browser will respect those. So, if we have a rogue script that potentially wants to then include something else from, I don't know, danger.com, I don't know, then this will not be allowed. And also just having a function that is self-evaluated will not be allowed here as well. So, this is already quite good.

Great. Second thing I want to mention before I wrap up is you can also mitigate here by using a discovery service as we saw before. And so, this also comes in handy here because what the discovery service can do is it can scan for vulnerabilities in your microphone. So, it can detect what packages are used and it can then work against the databases with the known vulnerabilities. And so, it can inform you when one of the dependencies that you're really using is having a vulnerability. So, this is really great because unlike the vulnerability reports that you get from NPM, which also include all your dev dependencies and everything, this really deals just with the runtime dependencies. And so, you will also just get really, let's say, great reports. So, all good. And this is how it could look in such a discovery service. Here we see everything is fine for, put it, dependencies. So, well, quite nice. You get informed and you can even then block that these microphone ones are rolled out.

So, the conclusion I want to draw, first thing is always test everything. It's the same as for every other web application. You can even then test in, let's say, smaller compartments where you just say, I'll test only for this one microphone and do that through penetration tests. It won't be good, but the solution as a whole, that needs to be rock solid.

Second thing, as we saw, one important aspect is always ensure the authenticity. So, make sure that the microphone hasn't been tampered with and follow the principle of least privilege. So, you need to open it a little bit, but no further. So, this is the maximum you should go with your solution.

Finally, and this is something I didn't speak about here, but that's, of course, something you need to do, monitor what's happening in the runtime. So, all the logging solutions that are out there for the JavaScript space, especially, make use of your favorite one in here. You really need it. Since this thing is not distributed, it's a great way also to get more information about how your application is working as a whole. With this in mind, I hope you still have a great conference and get in touch if you want to know more. If you want to check out the Discovery service, scan the QR code and otherwise, stay frosty. Bye.