Discussions

News: New Article: Are Java Web Applications Secure?

  1. There are a lot of potential security issues in today’s Web frameworks. Authors Roberto Velasco and Gorka Vicente try to address these issues broadcasting information about web application risks from their website (www.hdiv.org) and through articles, or by collaborating directly with development teams of the Java web frameworks so that they integrate HDIV in their framework as a part of the default distribution. Read the article

    Threaded Messages (16)

  2. Seam support and security[ Go to top ]

    I'd be curious to know how JBoss Seam stacks up against these other frameworks in their evaluation, and whether they support Seam with their security framework. Does anyone know?
  3. Re: Seam support and security[ Go to top ]

    I'd be curious to know how JBoss Seam stacks up against these other frameworks in their evaluation, and whether they support Seam with their security framework. Does anyone know?
    I read it on their home page.
    we can use HDIV in applications developed in Struts 1.x, Struts 2.x, Spring MVC and JSTL in a transparent way to the programmer and without adding any complexity to the application development. It is possible to use HDIV in applications that don’t use Struts 1.x, Struts 2.x, Spring MVC or JSTL, but in this case it is necessary to modify the application (JSP pages).
    jsptube.com
  4. Re: Seam support and security[ Go to top ]

    Currently HDIV only supports applications developed with standard JSF components (Sun or MyFaces implementations) and it has been tested in this environment. Seam is based on JSF but it has more components than JSF standard components such as richfaces that aren't currently supported by HDIV. HDIV's JSF version hasn't been released yet and that's why it isn't included at our web site hdiv.org. Roberto Velasco HDIV team
  5. AJAX and _HDIV_STATE_[ Go to top ]

    It is nice to use _HDIV_STATE_ to solve some problems. I think that it also causes problems to work with AJAX, right?
  6. Re: AJAX and _HDIV_STATE_[ Go to top ]

    Yes you are right, it can be problematic with AJAX applications. HDIV needs to know all possible requests to the server, in consequence, before to send the response to the client, HDIV needs to collect all the information about: urls, parameters,... HDIV gets this information thanks to HDIV's custom tags, without any interaction from developers. In consequence, if you create a static url (without custom tags) or you create a request on the client using javascript, the request will be rejected. That means that you can't use AJAX with HDIV? Not at all, it's possible but you have to follow some rules: Use HTML response type for AJAX calls As you know, there are mainly three different response types for an AJAX response : XML,JSON,HTML If you want to use HDIV and maintain his architecture you have to use HTML response type, and the HTML have to be created using HDIV's custom tags. Otherwise HDIV isn't able to know automatically, which data is editable or which not, or which parameters are legal and which aren't,... In other words, if your response is an XML or JSON you will be forced to tell to HDIV programmatically, what are you sending to the client (parameters, non editable parameters, etc,..). If you have to handle this task by hand I think that you lose the principal advantage of HDIV. Use HDIV custom tags to create AJAX urls (AJAX requests have to include HDIV_STATE parameter) You have to add HDIV_STATE to all urls that are going to use as AJAX calls. These urls can be stored at javascript code but the HDIV_STATE is generated at the server side. With this rule it's not possible to tamper an AJAX call to the server. Using these two rules and if your HTML response include complete forms, there isn't any problem with AJAX and HDIV. On the other hand, there is another problem we haven't solved yet about AJAX and HDIV. If you want to update a form (for example updating a select) it requires a special call to the server that updates the state created previously. This functionality isn't still implemented but we hope it will be implemented in a short time. Some users have already requested AJAX support and we will try to implement it as soon as possible. Roberto Velasco HDIV team
  7. Re: Seam support and security[ Go to top ]

    I am currently trying to use HDIV for a web app that uses the JSF framework.  I read on an online discussion thread that you are working on a version that will include JSF. Do the HDIV version that supposts JSF in beta version by any chance to the point where one can test it out? I would appreciate the opportunity to try it out.
    If I wanted to use the current HDIV version as is for my JSF application, what are some of the changes that I would have to make in order to make this work.

  8. Re: Seam support and security[ Go to top ]

    I am currently trying to use HDIV for a web app that uses the JSF framework. Is the HDIV version that supports JSF in beta version or is it at a point where one can test it out? I would appreciate the opportunity to try it out.
    If I wanted to use the current HDIV version as is for my JSF application, what are some of the changes that I would have to make in order to make this work.
  9. To arrive at such conclusions, I find it strange that the authors have not made any effort to contact the framework developers. At least the Wicket team did not know this audit was happening, nor didn't we have any way to participate, or to set the record straight. It even looks like the "researchers" didn't do their homework particularly well. The integrity column looks strange to me. The availability of a hidden field component makes a framework (partially) insecure? WTF? You are not required to use it-with Wicket the use of hidden fields for state management has all but disappeared in my applications. My Toyota can drive 140MPH, which is 60MPH more than allowed. Somehow all the car testers find this to be one of the safest cars in the world. Add the fact that one of the solutions the HDIV authors propose later in the article uses hidden fields themselves. Contradictory, I thought hidden fields are insecure? I call bullshit here. I'm not a native english speaker, and most certainly not a security expert, but I really don't understand what the "NON EDITABLE DATA CONFIDENTIALITY" metric means:
    As well as guaranteeing data integrity, it is also important to guarantee data confidentiality. The client mustn't edit nor know the real values of each parameter. If we guarantee only data integrity but not confidentiality we can provide useful information for an attacker. This information can be use to complete another type of attack such as sql injection. So, it is important to guarantee non editable data confidentiality as well to reduce the risk of suffering any attack.
    The only defining sentence in this definition is:
    The client mustn't edit nor know the real values of each parameter.
    What are you talking about? If you don't add something to a page, it is not known to the client. I'd say all frameworks have this ability, yet this column is strikingly red. The part about generic validation is also utter crap. We live in an international community nowadays where multilanguage/characterset applications are the norm, not the exception. If I would limit input for the whole application to just A-Za-z0-9, my clients would lynch me: nobody would be able to enter names for example. Perhaps the US doesn't have immigrants from Germany who'd like to properly write their name like Gößels instead of Goessels. In any case, this is easy to solve for any framework by creating a filter that removes all non-ASCII characters. Not that anyone with a tiny bit of intellect would do such a thing. Regarding the security token: with Wicket you can set the application to generate encrypted URLs for all actions and links. This is a two line configuration setting in your application. Even Google knows how to find this: Wicket encrypting urls. When you claim to work with the framework authors, it is strange that you didn't know this. The developers of the frameworks all take security very seriously, I know for a fact that the Wicket devs are serious about it. But publishing this type of uninformed and unchecked articles puts the efforts of the developers in a bad light and creates undue strain on their already limited time answering shitty questions about nonsense claims in unfounded articles. Already we have on person asking us to "fix the security issue of HiddenField".
  10. Security Token First , my apologies about this point. It's clear that we have made a mistake in this point. We will try to fix it as soon as possible. We know that it's possible to cipher urls but we didn't know that it's possible to apply it to actions (forms). Contact with wicket authors You are right that we haven't talked with wicket's development team. As you can see in the article, we have written "collaborating directly with some development teams" (especially with Struts team) not with all development teams. Integrity About hidden fields I don't think we have made any mistake, in wicket you can tamper hidden fields. Many people use hidden fields in order to store critical data. It doesn't mean of course that you have to use hidden fields in order to use wicket. When we talk about wicket as "partially secure", we are only talking about non editable data integrity. From an integrity point of view, wicket is the most secure web framework we have seen, that's why we have added to our article against the interests of HDIV because this is the main benefit of HDIV. Note that we have written "Wicket has only one component (HiddenField) vulnerable to integrity attacks". You are right when you say that HDIV needs hidden fields (only for cipher and hash strategies) but they are secure by default, you can't tamper them. I don't know how can HDIV handle client state management without hidden fields. I know you can use session (it's possible in HDIV) but it's not the best option from an scalability point of view. Non editable data confidenciality It means that you don't expose the real values (the model values) within the HTML page including: urls parameters values, hidden fiels parameters values,.. For example if you have a select like that: 1 2 3 Non editable data are: 34, 56 and 100 You are right when you say "If you don't add something to a page, it is not known to the client" but we are talking about to do it automatically, transparently, without any development work, in other words, by default. All vulnerabilities presented in this article can be solved programmatically with any web framework. I don't know why wicket handle non editable data integrity (excepting hidden field) if developers can do it by hand. Generic validations for editable data It's clear that in many cases you can use this type of rules (acceptedPattern), we are not saying that you have to use them in all cases, only that you have the posibility to use them when you can. On ther other hand it's important to note that there are two kind of editable data validations within HDIV: acceptedPattern and rejectedPattern The example you have commented is an acceptedPattern but I think it's useful and possible for any web application (including wicket applications) to apply rejectedPatterns in order to detect possible attacks agains editable data (textbox and textarea) in a generic way. About wicket I'm sorry if we have generated a negative effect for wicket, personally I don't think so. I hope that other people can read the article about wicket in a positive way because as you can see, it has been the best framework within the group analized in the article. I know that wicket's team is worried about security. Maybe you won't believe me but that's why we have added wicket to this article. Roberto Velasco HDIV team
  11. .NET, HDIV Performance?[ Go to top ]

    A few of these seem similar to the VIEWSTATE/EVENTVALIDATION that is available in .NET (curiously, that doesn't appear to be taken into account). Or am I missing something? How is performance of the apps affected by the inclusion of HDIV? While I don't disagree with it, I know one of the thing .NET stresses (and I am not a .NET expert) is that you need to be careful because of the hashing/conversions and amount of data processing. (in the .NET world, there's a lot more which gets sent to the client). I also do agree with the relative values instead of real values being sent to the clients, but it would seem like this is another performance hit and something that should be on the developer. After all, if in some cases the developer is indexing the values, then HDIV is doing it a second time.
  12. Re: .NET, HDIV Performance?[ Go to top ]

    HDIV's architecture is very similar to .NET or JSF because HDIV needs to manage a state and I don't think there are many alternatives for it (web session, hash, encryption). But there are some differences: - State's Size: HDIV's state is smaller because (at least in JSF environments) it stores only data about non editable information, omitting other kind of data. - You can disable: you can use HDIV when the application is critical or when you need an strong security and use a lighter architecture (Just Spring MVC for example) for other aplications. it's possible to apply HDIV just to a part of your web application. About the performance you can see our documentation about HDIV performance at: http://www.hdiv.org/docs/hdiv-performance.pdf Note that we are comparing an insecure application that doesn't do anything to validate integrity with the same application powered by HDIV. In other words, we are comparing the performance overhead added by HDIV. That means that if you compare a secure web application that validates correctly all incoming data (the problem is how, it's difficult to define a standard solution to perform a comparation) with an insecure application securized by HDIV the performance difference will be more closer. As you can see at the documentation the results confirm well-known rules: - web session: perform the best but it's the worse from the viewpoint of scalability - hash: perform worse than memory but it's better from the viewpoint of scalability (consume less web session) - encryption (via software): perform the worst but it's the best from the viewpoint of scalability Which is the best solution? In my opinion it depends what are your requirements. If you have an small application without clustering maybe it's better to use web session or memory. If you have a large application with a cluster and you need scalability you should use encryption strategy , if it's possible using hardware encryption. At this point I have to make a question, do you think SSL performs well? If you have a cluster and you need good performance do you use SSL via software? I have never listened to nobody saying that they aren't going to use SSL because it makes the application slower. That's true but we accept it because we need security. Large applications with large requirements use SSL via hardware, this is in my opinion the best solution for state management if you need good scalabity and good performance at the same time and of course, application level security. Roberto Velasco HDIV team
  13. Re: .NET, HDIV Performance?[ Go to top ]

    Roberto: I think your SSL Question is out of context. The purpose of it is significantly different than that which HDIV is claiming to protect. SSL is in the right location for its job -- preventing data from being sent in the clear across the network. It also has both a client and a server side actions. The reason I ask these questions is because I think some frameworks, while their intentions are good, lead to poor development. Everyone seems to be focusing on front-end security and as such the business layer tends to be forgotten and other entry points get missed. At least that's what I've seen. So, the question isn't is HDIV better than nothing. The question is it better than the validation occuring at the data layer and value hiding happening within the front end when needed rather than having an entire HTML string reparced and manipulated?
  14. Re: .NET, HDIV Performance?[ Go to top ]

    Totally agree with you, this is the most important question. About SSL: When I talked about SSL, I talked just from the viewpoint of performance. But I totally agree that SSL is not debatable and HDIV is, of course. My intention was to reflect that an application powered with HDIV (with encryption), is very similar to an application powered with SSL, from the viewpoint of performance. Take into account that when we are using encryption with HDIV we are encrypting 5-10% of the HTML (only non editable data), instead of 100% of SSL. About your question: First I don't know exactly what frameworks (besides HDIV) are you talking about when you say that "lead to poor development", please could you give me more information about this? In an ideal world I have to recognized that I could doubt between your two options, especially in small applications, but take into account that this is my ideal world: - you have a lot of time to develop your application - all developers are experimented developers and implement secure code - you have time and money to make a strong security audit - you have a good security architecture and design .... Unfortunately I don't live in an ideal world. I agree that if you use HDIV and you don't control the development process you maybe get a poor application but the same happens when you define a group of "Best Practices" and you don't control them or the development team is not good enough. Let me explain my proposal and what we are using in practice. First, I believe in layered security, sometimes it can add an overhead but if you need security in my opinion you don't have more options. We usually use Spring security for: - Authentication (X.509) - Access control: url, screen components and business method-level What about instance level security? In my experience this is the point where I can't define a clean and standard solution. I like the instance level security solution offered by Spring (I don't know more solutions in this area in Java) but we found two problems when we tried to apply it: - we work many times with legacy databases and we don't have acccess control data at database registry level - performance: we didn't get a good enough performance in our tests In consequence, we are solving instance level security by hand. At this point we could trust that all requests will be validated correctly (by hand) or we can add a security extra layer (HDIV) to avoid the risk (Note that HDIV solves more things than instance level security problems). In my experience the reality is that if you trust, you will get a partially secure web application. You can tell me that HDIV adds a performance overhead, that's true, but in my opinion (see performance documentation) you can afford it, as you can afford SSL overhead (that's why I mentioned SSL in my previous post), but can we afford an insecure application? Roberto Velasco HDIV team
  15. Re: .NET, HDIV Performance?[ Go to top ]

    Roberto: Thanks for the reponses. It's good conversation. I think hearing responses such as "unlimited resources/time/money is not realistic" is an excuse to drop quality. If you speak of small applicaitons, then the cost/time can't really be that big of a difference. If you are speaking of large applications then the cost of having to fix it later is going to outweight the cost of doing it right the first time. I'm not asking for perfection, but something better than "good enough" or nothing. I do agree with layered security. The issues that I've seen (and again, this is not due to framework flaws, but the perception they give) is that it lulls developers into not putting validation in the business layer (I'm coming from an enterprise development shop). I am not saying HDIV is not worth using (I've actually played with it and liked some of it). It was more just that when doing the comparison it didn't seem fair since you were comparing it doing nothing which should never be an option (yeah, the idealist is coming out again). So the performance question came in because if I was doing some of the things I was supposed to be doing, what would the impact be? Granted, that's hard to figure because you'd have to determine which features are more process/time intensive and make assumptions. Thanks again.
  16. Re: .NET, HDIV Performance?[ Go to top ]

    Your welcome, thank you Evan. I agree when you say that it's possible get quality with realistic resources and it's not an option develop insecure applications. As you can see in the article we describe more security solutions than HDIV. Actually, is more an article about security than about HDIV, but the introduction to the article at homepage is not very suitable. As I told you before, some hand coded security tasks, such as instance level security, are prone to errors and it's advisable to have an extra security layer to eliminate the risk and avoid insecure applications. If you have a hand coded secure application (in theory secure) and you apply an extra security layer using HDIV maybe you are applying some security validations twice and it will affect the performance obviously, that's true, but this is the philosophy of a layered security architecture. If one layer fails (usually hand coded layer) you have the other to stop the possible attacks. In consequence, I suppose we agree that the more secure option is: secure application (the safest you can) + HDIV Is this solution acceptable from the viewpoint of performance? Yes it is. For example, using HDIV's memory strategy your secure application will perform 3% slower. Other comparation you can use is to compare a traditional Struts application with JSF. JSF architecture is more heavier because it needs to manage an state (bigger than HDIV's state). Is posible to use JSF applications? Yes it is. At this point if you decide that you want to improve your performance and you can't afford this overhead (I don't think so) you have to cut some of your security functionalities. For example, if I have to choose between HDIV layer and a hand coded custom instance level security layer in order to improve performance, I will choose HDIV without any doubt, why? because is not prone to errors My proposal: 1. Implement a secure application (url, method level, instance level) as much as you can 2. Use always HDIV or a similar functionality 3. If you need to improve performance, cut some security validations at instance level security layer. For example, if you have some slow SQL joins in order apply instance level security (to avoid OWASP - A4) delegate this responsability to HDIV and use faster SQL querys. The third rule is not advisable but if you don't have more options, you could apply it. Don't forget that HDIV offers a global security solution that not only avoid attacks, it also acts as IDS (Intrusion detection system). Roberto Velasco HDIV team
  17. Missing printable link[ Go to top ]

    A printer-friendly link for the article is missing.