0

I am working on a webprojekt where I in order to minimize session bloating are using primarily ViewScoped beans. But then I face the problem that I need to transfer clients usernames and passwords between my beans (to access the database etc.).

I have made a system where I am using flash objects to transfer usernames and passwords between beans such as this:

public String gotoNextView() {
    ExternalContext external = FacesContext.getCurrentInstance().getExternalContext();
    external.getFlash().put("user_name", (String) FacesContext.getCurrentInstance().getExternalContext().getFlash().get("user_name"));
    external.getFlash().put("password", (String) FacesContext.getCurrentInstance().getExternalContext().getFlash().get("password"));

    return "/../../next_view.xhtml";
}

But I am worried about whether it is somehow possible for a hacker to manipulate the client and thereby trick the server to expose the flash objects!

Another solution that I am thinking about is to store all the JSESSIONID's for the web application as keys in a Map with the usernames and passwords as values. To make that work I suppose that I need a callback method to be called when a user session ends or expires so that I can remove the relevant JSESSIONID from the Map. But the problem with that solution is that I am in doubt about what is the best way to implement the callback so that I can be 100% sure that the Map entry is removed before a new similar JSESSIONID is created by the server (even though I know that the chances are extremely small that it will happen in such a short amount of time). Also I am in doubt about what to with beans that are working with a JSESSIONID (a user) if for some reason the server discards the JSESSIONID before the bean (and for example database operations) is finished (as I then can risk that a new similar JSESSIONID is created by the server for another user which then might get mingled with the JSESSIONID and user the other bean is servicing)!

I Hope that someone with deep insight into the problem will write about what is the best practise and a 100% secure way to this (also I suppose that most people working with JSF webapp servers encounter this problem and therefore it would be helpful for others to know the best solution to the problem). Thanks.

Kim Jensen
  • 17
  • 4
  • You shouldn't store passwords ***anywhere,*** not even in sessions or request scope. The application should access the database as itself, not as the user. – user207421 Sep 04 '14 at 10:36
  • Is there a reason that you dont want to use the session attribute for the username? Holding only that information in the session will keep your session small and you avoid all the issues no? – Martin Frey Sep 04 '14 at 10:39
  • @Martin Frey: Are you talking about using the HttpServletRequest and HttpServletResposne objects? I just don't know how to do that! – Kim Jensen Sep 04 '14 at 13:00
  • @EJP I think that I need to store passwords somewhere to validate them! And why shouldn't I store them in beans? Is it possible to hack into beans? And what exactly do you mean with "The application should access the database as itself, not as the user"? – Kim Jensen Sep 04 '14 at 13:08
  • The password should be used only for authentication and then "thrown away". Once the user is authenticated that counts for the whole session of that user, so no password needed anymore. As for the `loggedInUser`: you could simply rely on Spring Security if you use that already. (Else take a look ;) ) - `SecurityContextHolder.getContext().getAuthentication().getName();` and then call your dao to fetch the `User` from the db if you need more. – Martin Frey Sep 04 '14 at 14:19
  • Just stablish a password for application access, as @EJP says. Then you can make your application read a file where they are stored ([never hardcode](http://stackoverflow.com/questions/442862/how-can-i-protect-mysql-username-and-password-from-decompiling) them in your code). The application will have limited access to the DB then. The actions performed by you application might be controlled by your MVC layer. – Aritz Sep 04 '14 at 15:36
  • @Martin Frey: Thanks for your reply. About Spring then I have never used it before! But is using Spring the only and/or best way to do solve the problem? – Kim Jensen Sep 04 '14 at 17:08
  • @EJB and Extreme Biker: Thanks for your replies. It's not about the application password to the database (and of-course you are right that the db password should never be hardcoded), but all about the thousand of users accessing a webapp at the same time. And to save resources I do not want to use SessionScoped beans – Kim Jensen Sep 04 '14 at 17:19

1 Answers1

1

I think you're under a misconception here. The fact that a variable resides in one managed bean, and then is "passed" to another managed bean does not mean that there's actual movement across a physical medium. All viewscoped beans are implemented in the same storage area (I believe it's the UIViewRoot object). At this level, there's an implicit Boundary of Trust between these entities, and unless there's user-accessible movement between the two beans (maybe a client side variable, URL parameter or other HTTP artifact), I don't see the risk.

What this means is that, regardless of the specific @ViewScoped bean the variable sits in, they're all exposed to the same vulnerability (if any). "Passing" a variable between the beans doesn't introduce any new risk. Unless you're displaying the values anywhere to the users (maybe in the URL or in a hidden HTML form element), there's no new risk introduced by the @ViewScoped object in and of itself (improper use of the scopes is a different matter).

Ultimately, if you're still concerned about it, just encrypt your stuff (consider the overhead) before handing the variable to another entity

kolossus
  • 20,559
  • 3
  • 52
  • 104
  • Thanks for your reply. I understand that it's all happening inside the Servlet as 'it all' gets compiled into a Servlet. I was just wondering if there somehow is a way to trick the server to expose its bean attributes and the flash objects (my experience is that what hackers can do sometimes can be very creative and beyond 'normal' ideas of what is possible)! As far as I know then it is not possible for at hacker to 'get inside' a bean unless the whole server is compromised, and then all solution will fall! But maybe using Spring security or something else is a better solution to the problem? – Kim Jensen Sep 04 '14 at 19:01
  • Just to make my question more clear, then what I mean with a hacker hacking into the beans or flash objects, is that whether it is possible or not to create some sorts of advanced GET or POST requests to access the bean attributes or flash objects! I need the most 'paranoid' JSF related security system possible! – Kim Jensen Sep 04 '14 at 19:30
  • I'm also thinking about that maybe some DDoS attacks or maybe buffer overflow attacks can make the Servlet do unexpected stuff that might expose bean attributes and/or flash object. Or maybe whatever a hacker can do could compromise my JSF webapp somehow! – Kim Jensen Sep 04 '14 at 19:44
  • Sorry @KimJensen, until you can highlight a specific threat, you'll be chasing shadows. There's good design behind the MVC model, which JSF implements. Unless you're able to identify a specific scenario in which a server-side variable would find its way into the view, you're not [KISSing](http://en.wikipedia.org/wiki/KISS_principle). Identify a vulnerability on this [top 10 list](https://www.owasp.org/index.php/Top10#OWASP_Top_10_for_2013) or this [JSF vulnerability list](https://www.owasp.org/index.php/Java_Server_Faces) – kolossus Sep 04 '14 at 19:49
  • 2
    @KimJensen, a buffer overflow attack is [very unlikely](http://stackoverflow.com/a/479738/1530938) in java and and if you know what a DDoS attack is, you should know it would not result in server-side variables leaking to the client (barring shoddy coding). You're approaching web application security all wrong. "whatever a hacker can do could compromise my JSF webapp somehow!" is not a security strategy and you'll end up making mistakes. If you're worried about your app's security, you need to devise a coherent, cohesive security approach and not random paranoia-driven security "features". – kolossus Sep 04 '14 at 19:51
  • Like I said at the end of my answer, the catch-all scenario would be to encrypt your variables inside all your components - a waste of processing time in your scenario – kolossus Sep 04 '14 at 19:58
  • I've also heard that JSF is probably the most secure solution available and that's why I'm using it. But still almost everyday I hear about systems that were supposed to be secure being compromised anyway! Therefore I'm asking if somebody maybe can see a problem with my solution and if there might be a better as close to completely secure as possible solution available. – Kim Jensen Sep 04 '14 at 20:12
  • I'm thinking that if I at login combine the JSESSIONID with the username, and then from that calculate a SHA256 checksum and store it and the JSESSIONID in the database (attached to the username). And then I can send the checksum though the flash objects and use it to access the users info in the database (as I can just search for the checksum and check if the associated entry gives the right checksum (by recalculating it from the username and JSESSIONID) equal to the one that comes from the flash object). Then if an attacker gets the checksum then it will be of no use after the session ends! – Kim Jensen Sep 04 '14 at 20:55
  • Well, actually I don't even need to recalculate the SHA256 checksum as I can just compare it to the one calculated at login and stored in the database together with the username! (supposed that I discard the checksum for the session after the user session ends) – Kim Jensen Sep 04 '14 at 21:10