11 ms·

Unfortunately one of the examples used in the article introduces an SQL injection attack vector. Don't build parametrized SQL out of Strings.

• invalidname 4y ago
  That's from here: https://openjdk.org/jeps/8273943 https://openjdk.org/jeps/8273943 It doesn't. That's not a plain string replacement...
• littlestymaar 4y ago
  And email validation is done with a regex… This low-effort post really doesn't deserve the front page…
  • invalidname 4y ago
    This was copied from the original article linked by this article...
  • edp 4y ago
    This was code from another article, linked in the introduction.
  • ipaddr 4y ago
    How would you do it
    • papercrane 4y ago
      Check that its a string containing '@' with at least one character before and after the @ symbol is usually the only sensible thing to do. The format for emails is surprisingly complex, and while you can use a regex to catch 99% of the right values, it's very difficult to get it 100% right. Often the best thing to do is just to try and send an email to the address a validation link.
      • __ryan__ 4y ago
        Check that its a string containing '@' with at least one character before and after the @ symbol is usually the only sensible thing to do. This is exactly what the regex in the example is doing.
        • papercrane 4y ago
          The regex is ^[^@\s]+@\S+$ This would reject valid email addresses using quoted parts like john."@".doe@valid.example. Edit: Looking at it closely it looks like the attempt is to reject anything with an '@' in the user part, which would be an error (e.g. john."@".doe@valid.example). Except since "\S+" also includes '@' this regex will still work, but by accident. It would reject the valid email john."\ ".doe@valid.example
          • __ryan__ 4y ago
            I don't think that's true. In JS: /^[^@\s]+@\S+$/.test("john.\"@\".doe@valid.example") == true Edit: Hmm, I see what you mean. At first glance I thought it was just checking that it didn't start with @ or whitespace.
            • papercrane 4y ago
              Sorry, I edited my comment and then noticed you replied already. It's working by accident since the '\S+' will match the second '@', but if you had a quoted space in the user it would not work e.g. john."\ ".doe@valid.example, but would work with john.@.doe@invalid.example which I believe the regex is author meant to be caught as invalid.
    • littlestymaar 4y ago
      Two options: - use a library that implements RFC 5322 properly. - don't validate the email address (that is, don't try to reject most invalid addresses) and just check that the field contains at least one `@` to be sure the user didn't enter something else than his email address by accident. Tying to perform email address validation with regex you're writing yourself is the best way to reject perfectly acceptable email address and get frustrated users.
    • mrkeen 4y ago
      Parse, don't validate. https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
• jerven 4y ago
  I think you are talking about this example: ResultSet rs = DB."SELECT * FROM Person p WHERE p.last_name = \{name}"; This when it becomes valid java will not allow an SQL injection attack. The name part would be properly passed as a parameter. Not a string concatenation. Per https://openjdk.org/jeps/430 https://openjdk.org/jeps/430 If that was not the example you where thinking about, sorry :) Otherwise yes don't build parameterized SQL out of strings !
  • drdec 4y ago
    Thanks for the correction
  • jhhh 4y ago
    My main complaint about this new feature is that it has such poor conceptual clarity that people already familiar with Java will almost always misinterpret what is happening in exactly the same way. I've seen people post similar comments to the one you're correcting on reddit as well.
• __ryan__ 4y ago
  You are thinking of string interpolation. The idea behind string templates, the feature the example is showcasing, is effectively a way to define a function that can be called with similar syntax to string interpolation. So DB."SELECT * FROM Person p WHERE p.last_name = \{name}" would basically be a function call like DB("SELECT * FROM Person p WHERE p.last_name = ", name), which would do the right thing to parameterize the SQL.
• jbverschoor 4y ago
  So you're talking about a preview/beta/new feature (TemplatedString), and use that as the reason it's "still" popular?
  • __ryan__ 4y ago
    First of all, yes, new features alone can make something maintain popularity. Why would that not be the case? Second, the author was using that as an example of Java showing a pattern of adding syntax improvements, which again might be something that maintains popularity. Finally, from the article: But let's talk about the Java we have today, not the one coming in 6 months. It was just one talking point. Did you even read the article?