LoggedInOutlet is insecure

[smyth64]

On line 27 of the LoggedInOutlet you say:

if (!this.publicRoutes[url] && !localStorage.getItem('jwt')) {

So if I set my localStorage item 'jwt' to any value, I am authenticated. You are not checking, if the jwt token is valid.

Pretty simple to hack :)

[chenkie]

Very true :) However, no amount of protection on the front end is going to fully secure a browser-based (SPA) application. Anyone with enough knowledge and motivation would be able to force protected routes to become available if they wanted to.

Luckily, that's not the point. The stuff that is actually sensitive is the data that is retrieved from the backend and displayed on the front end. Since we're protecting the app with JWT, the user wouldn't be able to get at any of the data on the backend if they didn't have a valid JWT anyway. So while they might be able to get to a front end route that we'd like to keep them away from, it won't be of any use to them once they get there because they won't be able to get any data for it.

[smyth64]

I cannot fully agree with this.

It is possible to fully secure a route even on the frontend. Achieving this you just have to make a small "Authentication Check" on every route change. And if it fails, the user gets redirected to /login.

[chenkie]

Yes you can make a call to the server before changing routes to verify that the JWT is valid, but even that wouldn't be enough for those with enough hacking determination. Remember that in many cases, all of the code that the Angular app needs for all of its routes to work is delivered to the browser when it loads. That means that the JavaScript necessary to construct the private route is sitting there available for hacking.

I have no idea how you'd go about manipulating the client-side code to force navigation to a private route, but the important part is that the code is there on the client and not protected by the server.

Angular 2 gives us some interesting possibilities with async routing, which allows for the code for a given route to stay on the server until the route is navigated to. Perhaps this is one way to truly protect client-side routes, I don't know.

The question I would have is why would you want to take a chance on including sensitive data on the client side? If you wouldn't be including sensitive data in the client side then why would it matter if the user can force their way to a private route that is just an empty shell?

[felippeDev]

Yes, sad but true... I was thinking abalou uses a jwt token encrypted by webApi using rsa and auto-refreshing.. This feature combine with CORS could make things a little bit painfull to our cracker but still not enougth .. The cracker always can use an alien client to get jwt and decrypt using some kind of tunneling tool to pass thru CORS protection and try the access ... There's no silver bullet to resolve these issues... But tks, your code help me a lot and save some time!! Good job!

[sonicoder86]

Now it has been replaced by guards in routes.