3 ms·

I would think that this was introduced at the same time as SNI was enabled for Lynx (2009-04-26 from the changelog, but I haven’t checked if it was actually vul

I would think that this was introduced at the same time as SNI was enabled for Lynx (2009-04-26 from the changelog, but I haven’t checked if it was actually vulnerable at that time). I don’t know if I’d call any URL processing issue basic though, I can safely say that I’m never even going to attempt to write a URL parser, just because of the number of potential edge cases. You can imagine when you’re enabling a (fairly simple, compared to the rest of the TLS spec) extension, you might not be thinking about all the different quirks of the URL spec which could occur and mess up what seems like a basic change.

nly 5y ago
URIs have a generic grammar defined in RFC 3986. However, this doesn't cover DNS name validation for the hostname: "This specification does not mandate a particular registered name lookup technology and therefore does not restrict the syntax of reg-name beyond what is necessary for interoperability" It also doesn't constrain the userinfo ("username:password") part described in this vulnerability. So yeah, it's non-trivial.
- tialaramex 5y ago
  I don't see what's "non-trivial" about the decomposition: authority = [ userinfo "@" ] host [ ":" port ] described in section 3.2 of that specification. Looks pretty trivial to me.
  - nly 5y ago
    It's non-trivial because the userinfo part is not structured in the grammar, but is instead just constrained to a particular character set. The RFC reads: > Use of the format "user:password" in the userinfo field is deprecated. In the real world, for HTTP use cases, you can't just ignore this because it's deprecated.
    - tialaramex 5y ago
      > the userinfo part is not structured in the grammar, but is instead just constrained to a particular character set. Yes. So, a correct implementation can't use this document to destructure it, but that's OK because it doesn't need to do so. It can however easily distinguish the userinfo from the rest of the authority. Unless, like this code, it simply doesn't bother to try. > In the real world, for HTTP use cases, you can't just ignore this because it's deprecated. Then I guess you'll need to write code to further parse the userinfo. Seems pretty easy, but this document doesn't explain how because it's deprecated. No impact on whether you can find the host name in the authority since that's a separate field from userinfo. Assuming, of course, that you bother to separate userinfo from the domain name in the authority, which Lynx did not.
- admax88q 5y ago
  You don't need to validate the hostnamez you can safely leave that for name resolution libraries. You just need to properly separate the user info from the host name and port. Which is pretty simply defined in the grammar.
  - nly 5y ago
    That depends on your use case. If you're trying to check the hostname against some sort of whitelist or blacklist you're going to want to normalize it. Then you have all kinds of fun like IDN to deal with.

nly 5y ago

URIs have a generic grammar defined in RFC 3986. However, this doesn't cover DNS name validation for the hostname: "This specification does not mandate a particular registered name lookup technology and therefore does not restrict the syntax of reg-name beyond what is necessary for interoperability" It also doesn't constrain the userinfo ("username:password") part described in this vulnerability. So yeah, it's non-trivial.

tialaramex 5y ago
I don't see what's "non-trivial" about the decomposition: authority = [ userinfo "@" ] host [ ":" port ] described in section 3.2 of that specification. Looks pretty trivial to me.
- nly 5y ago
  It's non-trivial because the userinfo part is not structured in the grammar, but is instead just constrained to a particular character set. The RFC reads: > Use of the format "user:password" in the userinfo field is deprecated. In the real world, for HTTP use cases, you can't just ignore this because it's deprecated.
  - tialaramex 5y ago
    > the userinfo part is not structured in the grammar, but is instead just constrained to a particular character set. Yes. So, a correct implementation can't use this document to destructure it, but that's OK because it doesn't need to do so. It can however easily distinguish the userinfo from the rest of the authority. Unless, like this code, it simply doesn't bother to try. > In the real world, for HTTP use cases, you can't just ignore this because it's deprecated. Then I guess you'll need to write code to further parse the userinfo. Seems pretty easy, but this document doesn't explain how because it's deprecated. No impact on whether you can find the host name in the authority since that's a separate field from userinfo. Assuming, of course, that you bother to separate userinfo from the domain name in the authority, which Lynx did not.
admax88q 5y ago
You don't need to validate the hostnamez you can safely leave that for name resolution libraries. You just need to properly separate the user info from the host name and port. Which is pretty simply defined in the grammar.
- nly 5y ago
  That depends on your use case. If you're trying to check the hostname against some sort of whitelist or blacklist you're going to want to normalize it. Then you have all kinds of fun like IDN to deal with.