Admin part of code is exposed to the non admin clients.

[lubo08]

I think that problem is that also admin parts of html are exposed to the client even client is log in as user not admin still there is admin code. This can't happened in secure application. Just use thymeleaf with spring security to do not expose this part of code to the client.

`

Administration

•  User management
•  User tracker
•  Metrics
•  Health
•  Configuration
•  Audits
•  Logs
•  API
•  Database

            </li>`

[jdubois]

No, we can't serve it with Thymeleaf, this is pure static HTML pages, so you can serve it from an HTTP server or from a CDN. There is no security risk, it's just presentation code.

[deepu105]

this is not gonna happen and this is not an issue, its only the html thats loaded and not the data, without the data this doent pose any security concern

[deepu105]

@jdubois you beat me to it :P

[lubo08]

OK but is not security issue if me as a hacker I'm able to see what admin can do? This help so much to discover weakness of the system. Doesn't matter if there are data or not. User shouldn't see what is admin able to do. And even to see what is the way to do this. admin links etc.

[deepu105]

I dont know what weakness one can discover from html code!! In that case the client side js code you expose can expose way more weakness than any html by your logic

Thanks & Regards, Deepu

On Wed, Mar 23, 2016 at 11:27 PM, lubo08 notifications@github.com wrote:

OK but is not security issue if me as a hacker I'm able to see what admin can do? This help so much to discover weakness of the system. Doesn't matter if there are data or not. User shouldn't see what is admin able to do.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/jhipster/generator-jhipster/issues/3246#issuecomment-200393678

[lubo08]

https://en.wikipedia.org/wiki/Attack_surface

Just simple rule even with OWASP security. Minimize risk as possible and do not expose and of course also admin parts of javascript is included also. just split admin javascript code and do not include to html if user is not admin.

http://www.pcquest.com/reducing-attack-surface-software/

[jhulick]

@deepu105 the primary issue as I see is not about exposing admin html code but the security roles to the client. A hacker could determine privilege escalation by looking at the data roles within markup. With that said, I've commented on the closed issue #1293 with my opinions and also agree with you and @jdubois. If more security is needed, a developer could modify the generated app and use Thymeleaf (though not an ideal scenario).

[deepu105]

I understand were you are coming from but these are concern only for extremely secure apps. for normal scenarios presentation code shouldn't cause a security concern. For your concern about roles on the client I have something to fix that but will need to find some time to do that on the generator but could be soon.

So yes if you are overly concerned you can use thymeleaf we ship it OOTB anyways but the default setup will remain as it is for now.

[lubo08]

Just please consider this as I would like to use it for bank applications also. I think this is great project so I think can't be so hard thinking little bit more secure. Just consider that If hacker have admin look and feel can much easier prepare some social attack and create some admin looks website and send link to administrator to fill some sensitive data. You never be ready to prevent against this social attacks. But you can minimize risk as much as possible. Can't be hard a little refactoring with more than 200 contributors :) And this project is not about some application this project is base for any kind of application eve those with highest security needs.

[gmarziou]

@lubo08 what about contributing yourself? I'd be curious to see how you'd implement this and deal with angular template caching and ui routing.

[deepu105]

I would rather rethink my architecture for such critical app. You should probably consider a microservice like architecture with a gateway for public access (this shouldn't have any admin stuff in it at all ) and a dedicated gateway for admin (this shouldn't be exposed to public and should be behind a firewall/reverse proxy)

You can reuse some backend services between the 2 gateways. This would ensure that you have less risk and will keep your assets safe from public.

It would be very risky to have both admin and public part of a banking site on the same app. On 24 Mar 2016 06:56, "Gaël Marziou" notifications@github.com wrote:

@lubo08 https://github.com/lubo08 what about contributing yourself? I'd be curious to see how you implement this and deal with template caching and ui routing.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/jhipster/generator-jhipster/issues/3246#issuecomment-200574823

[jdubois]

Yes, if that's your need, just do 2 gateways, one public and one private. You shouldn't have your admin API opened publicly anyway.

[lubo08]

OK thank you just even this app will be inside private network. Security audit didn't allow application with public admin parts. of course API will be protected but also html sources and javascript have to be protected. Maybe generator should offer if you want use angular templates or completely run on thymeleaf templates.

[japharr]

You can also use the login user role in the server code to determine what will be returned to the html view..

[jdubois]

I agree this isn't clearly explained on our website, we should update the security section. Le 24 mars 2016 8:28 AM, "Jaleel Adesina" notifications@github.com a écrit :

You can also use the login user role in the server code to determine what will be returned to the html view..

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/jhipster/generator-jhipster/issues/3246#issuecomment-200704043

[lubo08]

Maybe this could be the way https://dzone.com/articles/thymeleaf-fragments-and Just even for single public application not so much with security concern I do not want to have public admin parts and micro-service environment is not always the case. Just would be nice to have this as default.

[deepu105]

@lubo08 Sorry but as myself and @jdubois highlighted we wont be doing this in the near future as there is a way to do your use case more elegantly (using a microservice architecture which we would suggest)

[lubo08]

So any of users who use jhipster without micro-service architecture are not concern about social attack when hacker mask own site to admin page of your site and sent this to your users? What you think how many of 100 users will fill this form with sensitive data (password, credit card number, etc.)? 5% 10%?

_So if I'm concern about security have to chose micro-service or otherwise I didn't have to concern about security. _

Right now I'm working on project where micro-service architecture is not possible.

Anyway thank you for help and discussion about this.

[jdubois]

JHipster is just a generator, it can't do everything for everyone. What you describe here is an incredibly complex attack, with someone un-scrambling the minimized admin screens, changing them so they work with another backend, managing to trick users into using his website (and that means people entering their credentials on another website! Isn't this really complex??)... So if you have such a need, then don't expect a generator, which by its nature is something very generic, can do it. We have also a focus on performance and usability, and the current security is very good: in 2,5 years, with nearly 200,000 downloads, we have never, ever had a security vulnerability. I'm not saying what we we do is perfect, but it's secured enough for most people. If you don't like or want the admin screens, then just remove them: it's just a generator, those screens are not mandatory. If you want to serve them with Thymeleaf, that's probably very easy to do, too. By default I wouldn't do this, but for your specific use case you can choose to do it.

[deepu105]

I think you are just exaggerating something which is a very rare case. If you choose to have admin and public part of a very sensitive app on the same package then you have more architecture security concerns to worry about then static presentation asset which possess minimum risk.

To me you have choose a poor architecture for a very sensitive app. I work for a big enterprise client and I would never put my admin into the same app which is open to public.

You should really reconsider your architecture if you want to be extremely safe against any attack. I would never put my admin stuff on the public facing part of my network even if it has all admin static assets hidden away as you suggest.

[deepu105]

@jdubois we are always in sync :joy: