Discussions

News: A Hibernate Urban Legend

  1. A Hibernate Urban Legend (35 messages)

    Somewhere along the line Java developers came to believe that Hibernate protects you from SQL injection. I'm not sure where they came to believe that. Maybe it is because you no longer have to write SQL and Hibernate does many other magical things - it has to protect you against SQL injection. I'm tired of telling Java developers that HQL has the same vulnerabilities as SQL, they don't believe me and think Hibernate offers them some sort of magical protection from bad HQL. Basically, what I term bad HQL is when named parameters are not used. Consider the following example: String goodParameter="Raj lane"; Query badQuery = session.createQuery("from Address a where a.street='"+goodParameter+"'"); I have SQL logging turned on so I can see that the generated SQL is as follows:select address0_.addressId as addressId, address0_.street as street1_ / from Address address0_ where address0_.street='Raj lane' Now consider the following where I attempt "HQL Injection":String badParameter="la' or '1'='1"; Query reallyBadQuery = session.createQuery("from Address a where a.street='"+badParameter+"'");And the resulting SQL:select address0_.addressId as addressId, address0_.street as street1_ / from Address address0_ where address0_.street='la' or '1'='1'Note that the above SQL passes the parameter directly into the SQL. The generated SQL will return all rows in the table. Which is bad, but SQL injection opens us up to much worse attacks. So the moral of the story is to use named parameters, the above code can be fixed as follows:String badParameter="la' or '1'='1"; Query reallyBadQuery = session.createQuery("from Address a where a.street=:street"); reallyBadQuery.setParameter("street", badParameter);Rajesh Patel Harpoon Technologies http://harpoontech.com [Editor's note: This post seems to be a little overboard, IMO, because Hibernate offers you the manual query stuff to allow you enough rope to hang yourself with. Even the best language or library can't protect you from yourself. You know what they say: make something idiot-proof and someone will invent a better idiot. The warning is valid, though: use parameters, people!]

    Threaded Messages (35)

  2. Re: A Hibernate Urban Legend[ Go to top ]

    This posting should be called "A Database Access Urban Legend" because it applies to any dumb string concatenation when using any form of database access (PHP, Perl, JDBC, VB or ASP, etc.) Best Regards, Richard L. Burton III
  3. Re: A Hibernate Urban Legend[ Go to top ]

    This posting should be called "A Database Access Urban Legend" because it applies to any dumb string concatenation when using any form of database access (PHP, Perl, JDBC, VB or ASP, etc.)

    Best Regards,
    Richard L. Burton III
    I think that his point is correct. Many Hibernate developers think the rule doesn't apply to them, so they don't think about it. I have heard people say the same about Toplink. "oh I used Toplink I don't have to worry", and then you check their code and find parts of the code where they are using concatenated strings and pumping them directly into SQLCall objects.
  4. Re: A Hibernate Urban Legend[ Go to top ]

    On a somewhat related note...... Many people think if they have a door to their house, they don't need to worry about burglaries. But you have to lock the door...
  5. Re: A Hibernate Urban Legend[ Go to top ]

    The the title should be "How to spot a retarded Java Developer." It's pointing out something that anyone with half a brain can identify without thinking about it. Maybe talking about the Proxy the Hibernate uses on Load or something else would be of value. Just my few rude comments that's all :) Best Regards, Richard L. Burton III
  6. Please don't...[ Go to top ]

    use the word "retarded" for this purpose. It's a pity to use the unfortune of some people to insult others. What are you going to do next? Poke fun of the special olympics?
  7. Re: Please don't...[ Go to top ]

    I don't agree with "Political correctness". If you're seriously offended it, then you may want to avoid making indirect insults to the "Special Olympic". Next time I'll use the word "Sped". Best Regards, Richard L. Burton III
  8. PC[ Go to top ]

    "I don't agree with "Political correctness"" Neither do I. You're a complete f&^%ing moron. See? You can be on the receiving end of non-PC, you stupid f&ck-face. ;) Seriously, none of your posts here have added anything to the original post. The original post was simply to keep sloppy programmers from assuming Hibernate automagically protects one from SQL injection. It doesn't, and you have to use the same techniques that you would with regular sql. But I do agree with the other guy. You shouldn't use the word "retarded", as there are actual people who are actually mentally retarded. The other guy might have a friend or relative or son or something that is actually mentally retared.
  9. Re: A Hibernate Urban Legend[ Go to top ]

    The the title should be "How to spot a retarded Java Developer."

    It's pointing out something that anyone with half a brain can identify without thinking about it.
    There are reasons that a developer would not even have to consider this risk, such as a limited interface that would make this impossible. It doesn't make that developer a retard. Cheers
  10. i'm so tired of code monkeys[ Go to top ]

    any developer who thinks this should be fired on the spot or demoted until such time as they can prove they really understand and care about what they are doing.
  11. +1. (but don't call'm code monkes). forgive!. Regards, -Rory.
  12. seriously sick of tss lately, everyday another AJAX framework, who actually uses all this crap!
  13. +1. And nobody mentioned shiny metal projectiles (yet).
  14. seriously sick of tss lately, everyday another AJAX framework, who actually uses all this crap!
    Hmm, lots here. First off, TSS is your site, too: if you have a suggestion, feel free to throw it in the ring. Second: let's see, in the front page, there's:
    1. Rod Johnson Podcast
    2. Hibernate and SQL injection (this post)
    3. Chainbuilder ESB
    4. Atleap 0.53
    5. Project jMaki (AJAX)
    6. Eclipse WTP
    7. ZK and Seam
    8. Serverside and clientside state with JSF
    9. Webcream (AJAX)
    10. WSO2 (AJAX)
    11. Free and paid support of Open Source
    12. TDD
    13. Sitemesh
    14. H2
    15. Widgetserver
    16. konaKart
    17. Clustered Drupal
    18. Portlet 2.0
    19. "number one ill of java"
    20. Atlassian acquires Cenqua
    Twenty posts. Three of which have AJAX relationships, which makes 15% of the posts. That's too many? I dunno - AJAX is not only all the rage, but it's billed as a viable way to interact with web applications nowadays. Since so many people use Java on the server side for web applications at some level, I think that's not too surprising. That said, I wouldn't be unhappy posting more "traditional" web app news, if there was news going on - but the market for web 1.0 frameworks and techniques is fairly saturated. Again, got a suggestion?
  15. I think TSS does a great job in mixing up the content. They cover things from OSGi, GWT, and more without being selected things on a personal preference. Since you asked Joe, :) I'd enjoy more coverage on GWT since its something I found to be very beneficial in terms of Web Development. Maybe something on the lines of the Widgets or covering multiple Modules in GWT on a single page. Best Regards, Richard L. Burton III
  16. "Number one Ill in Java" was the lowest point in TSS history IMHO.
  17. "Number one Ill in Java" was the lowest point in TSS history IMHO.
    Really? It's funny - I thought the post was interesting, which is why it made it to TSS in the first place. That said, I've gotten more negative feedback about that post than I would have imagined. I thought his message was, um, not quite extraordinarily valid - I mean, packages and classpaths are not only really simple, but super-useful, even if sometimes I really wish Java did have an equivalent to C++'s friend keyword. But the concept of a "number one ill" is something to consider. If something has a "number one ill," it's worth considering if only to figure out if there's a way to fix it. There is another thought-line here - the reason his "number one ill" exists at all is that the documentation isn't apparently clear enough for everyone - I have to say, classpath is an OLD, OLD question that gets asked all the time. That means something isn't right about it somewhere. I didn't post it because classpath is offensive. :)
  18. sometimes I really wish Java did have an equivalent to C++'s friend keyword.

    Something like that's been proposed with member packages in SE7.
  19. seriously sick of tss lately, everyday another AJAX framework, who actually uses all this crap!
    People who are intested in innovation? :)
  20. The solution[ Go to top ]

    There is a way to protect from SQL injection: If the database forces you to use parameters. So far only the H2 database supports this feature, called 'disabling literals'. Basically, the admin calls
    SET ALLOW_LITERALS NONE
    Afterwards, values can only be passed as parameters. If the application tries to embed values directly into SQL statements such as
    SELECT * FROM USERS WHERE PASSWORD='test'
    Then the database simply throws an exception. So the developer is forced to use:
    SELECT * FROM USERS WHERE PASSWORD=?
    This solves most SQL injection problems. For details see: http://www.h2database.com/html/advanced.html#sql_injection I suggest that the other databases and Hibernate add this feature as well. This mechanism is not patented. What do you think?
  21. Re: A Hibernate Urban Legend[ Go to top ]

    Oh..... Come on...... Any language that is being parsed and evaluated at runtime has that vulnerability. Say JavaScript's eval statement, the scripting support in Java 6.0 has the same potential vulnerability, if misused.
  22. Re: A Hibernate Urban Legend[ Go to top ]

    No, not every language. Only languages that allow embedding user input (in the form of literals). If Hibernate (or the database) doesn't allow PASSWORD='xyz', but only PASSWORD=$pwd, then it is _not_ vulnerable. That's what I suggest to do: enforce the use of parameters ($pwd).
  23. Re: A Hibernate Urban Legend[ Go to top ]

    As far as I understand, disabling literals will disable, well, all literals, not just those which supposed to be a parameter. For example the query like this becomes illegal: SELECT * FROM user WHERE role='admin' AND active='Y' AND login= Developer will be forced to use 3 parameters when he/she needs just one. Some may find this too intrusive. So other options I'd consider are 2) Use hibernate Criteria API. I believe it takes care of possible injections. 1) Establish the good data access pattern and keep it consistent across the project/product. While it takes more than just programming skills, the approach works, is not database-specific, not even problem-specific.
  24. Re: A Hibernate Urban Legend[ Go to top ]

    Developer will be forced to use 3 parameters
    Not if he uses Constants: SELECT * FROM user WHERE role=Roles.ADMIN AND active=TRUE AND login=? Constants are very common in regular programming languages like Java. Unfortunately, they are less common in SQL (I don't think there is a standard). H2 supports constants.
  25. For those databases that do not support constants, it's important to differentiate between literals used as (variable) parameters and literals used as constants in the query. In the example SELECT * FROM user WHERE role='admin' AND active='Y' AND login=? It can be very important for the optimizer to give these constants as literals: 'admin' and 'Y'. For example, if only 1% of rows have active='Y' the optimizer may choose to use an index to access the database. Whereas, if you blindly follow the "use bind variables everywhere" rule and put WHERE active=?, you may miss out on the index, even if you always use 'Y' for the value. Sounds like H2 does a nice job with this by promoting constants in SQL. I don't know other databases that do that though. John Hurst Wellington, New Zealand
  26. if you blindly follow the "use bind variables everywhere" rule and put WHERE active=?
    Yes, in some situations it may be a little bit slower. More important is, using bind variables where it's not necessary is not developer friendly.
    Constants in SQL. I don't know other databases that do that though.
    Databases will support it if people demand it. Protection from SQL injection sounds like a good reason.
    What is wrong with literal?
    Developers embed user input by using literals. That's the danger. What's wrong with pointer arithmetic, manual memory management? It's easy to make mistakes, so it's dangerous.
    If something is static then let it be static.
    Agree, but use constants. Anyway better for maintenance. Constants also help document the code.
  27. For those databases that do not support constants, it's important to differentiate between literals used as (variable) parameters and literals used as constants in the query.

    In the example

    SELECT * FROM user WHERE role='admin' AND active='Y' AND login=?

    It can be very important for the optimizer to give these constants as literals: 'admin' and 'Y'.[...]
    I wonder why nobody mentioned: CREATE VIEW find_active_admin AS SELECT * FROM user WHERE role = 'admin' AND active = 'Y'; so that nasty literal query becomes: SELECT * FROM find_active_admin WHERE login = :login That's a simplest way - if your backend supports views that is, but all good backends does.
  28. Using Seam helps[ Go to top ]

    Hmm, but if you are going to use Seam and you put an EL-Expression into the query-string then Seam protects you from SQL injections, IMHO. Regards, Frank
  29. Re: A Hibernate Urban Legend[ Go to top ]

    Why to do string concatenation, instead use named parameters. Sudhir
  30. Re: A Hibernate Urban Legend[ Go to top ]

    ...it applies to any dumb ... ...you have to lock the door... ...Why to do ..., instead...
    Like pointer arithmetic / manual memory management: Good developers are safe. Fact is: if you allow it, developers will make mistakes: Buffer overflow. Boom. Java doesn't allow pointer arithmetic / manual memory management. Java is safe. SQL injection is similar: Once you allow embedding user input in SQL statements, some developers will make mistakes. SQL injection. Boom. How to solve it? Don't allow embedding user input. Enforce the use of parameters. Then you are safe.
  31. Re: A Hibernate Urban Legend[ Go to top ]

    Hibernate claims it can protect the system from SQLInjection , because it provides Criteria which allows object oreinted query creation and not because of HQL
  32. Hibernate claims it can protect the system from SQLInjection , because it provides Criteria which allows object oreinted query creation and not because of HQL
    Criteria API is great, but you can write bad sql with that too. I think this is quite possible... sesssion.createCriteria(Address.class).add( Restrictions.sqlRestriction("street='la' or '1'='1'")); Tomi
  33. To exculpate literal[ Go to top ]

    What is wrong with literal? If something is static then let it be static. Why to put extra brain to make it dynamic I know you will loose the advantage of parameterized query but what if that query is called only once Regrads, Shabbir
  34. To exculpate literal[ Go to top ]

    What is wrong with literal? If something is static then let it be static. Why to put extra brain to make it dynamic I know you will loose the advantage of parameterized query but what if that query is called only once Thanks, Shabbir --------------------------------- Previous reply I posted with my old id.. so posting it again ----------------------------------
  35. BOYAN[ Go to top ]

    БОЯН
  36. i agree.... with "boyan" (bayan)[ Go to top ]

    +1 ------------------------------- ru coders use such slang-words for blame sush bAnal remarks