• (nodebb)

    Https://bank.com/onlineportal/transferfunds?login=whoneedsthis

  • (author) in reply to Mr. TA

    The good news is that they're calling a method which doesn't include the query string here. I had to double check that in the docs, though.

  • Rogan (unregistered)

    Beware the path parameter:

    https://bank.com/transfer;login?src=abc&dst=def&amount=1000.00

    See https://www.whitehatsec.com/blog/beware-the-http-path-parameter-in-java/

  • Robin (unregistered) in reply to Remy Porter

    That was my first thought too - does it check the query string? (I don't know Java, let alone whatever framework this is using.) At least then this is a mere code WTF not a "security" one!

  • ooOOooGa (unregistered)

    Yup. Certainly no need to enforce session access requirements for the /updateloginpasswords URL.

  • (nodebb)

    Another fine example of how anything is insecure when a person who doesn't understand it slaps ", Developer" at the end of their name.

  • (nodebb) in reply to Remy Porter

    OK I read the docs and the article mentioned by Rogan, and I wish I didn't. That whole API surface area is horrible. I was half joking, I don't know if there's actually a security vulnerability here, but boy do they need to clean all that stuff up. For example, they have 2 methods, getRequestURI and getRequestURL, which differ in behavior, and neither has a descriptive name for what it does.

  • Rogan (unregistered) in reply to Mr. TA

    The fun part is that path parameters are a legit part of the URL specification, see RFC 3986 Section 3.3:

    Aside from dot-segments in hierarchical paths, a path segment is considered opaque by the generic syntax. URI producing applications often use the reserved characters allowed in a segment to delimit scheme-specific or dereference-handler-specific subcomponents. For example, the semicolon (";") and equals ("=") reserved characters are often used to delimit parameters and parameter values applicable to that segment. The comma (",") reserved character is often used for similar purposes. For example, one URI producer might use a segment such as "name;v=1.1" to indicate a reference to version 1.1 of "name", whereas another might use a segment such as "name,1.1" to indicate the same. Parameter types may be defined by scheme-specific semantics, but in most cases the syntax of a parameter is specific to the implementation of the URI's dereferencing algorithm.

  • DrPepper (unregistered)

    The title of this article is way cool. I'm guessing that the title came first; then the author spent hours looking for a code snippet that would fit it.

  • MaxiTB (unregistered) in reply to Mr. TA

    Java likes to clean up anything and call shortcoming features or by design since it fall off the trash hill of a failed Sun OS :-)

    In all seiousness, the only reason why the avoid any changes at all is market share. They prefer to pile changes on top off everything. Sure, it doesn't make anything more secure but at least some managers are not forced to rethink if Java is actually the best choice.

  • jay (unregistered)

    Code at my company is filled with logic like if x=2 then return true else return false

    Why not just say, "return x=2"?

    This is especially annoying when the condition is just checking a flag. I've seen

    if active then
 return true
else
  return false

    How can it not be obvious that this is just a long way to say "return active"?

  • jay (unregistered)

    Not only does this set you up for a pretty obvious hack attack -- "URL injection"? -- like "http://www.example.com/foo?bar=login". But depending on what parameters might be passed in, someone could accidentally break it. I ran into an issue like this once, I forget now what magic word the programmer was looking for in the URL, but let's say "login" like here, and I got a call from the tech support people saying that the page worked fine for everyone except one user: Mr Blogindale. Just making up a name to go along with the word "login", but you get the idea. At first I didn't even consider the possibility that it was something about the customer's name. How could that possibly make any difference? Until I finally saw the url.contains("login") and had an epiphany.

Leave a comment on “It's Not What You Didn't Think it Wasn't”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article