HttpRequest::portReadable() does not return a value

[SvenRtbg]

static function PortReadable()
{
    $port = self::Port();
    if ($port=="80" && strtolower(self::Protocol())==self::PROTOCOL_HTTP)
        $port="";
    else if ($port=="443" && strtolower(self::Protocol())==self::PROTOCOL_HTTPS)
        $port="";
    else
        $port=":".$port;
}

[EnDe]

Why this check? There is no restriction anywhere to use HTTPS on port 80 or HTTP on port 443? This check does not comply to any defined standards, does it? (I mean standards like w3c, not common practice)

Sorry for bad news.

[abiusx]

Its not about the support, its about the readable port string. It would look odd if you had the following URL: https://abiusx.com:443/ but it would feel natural to have it without the port number. -A

---

Notice: This message is digitally signed, its source and integrity are verifiable. If you mail client does not support S/MIME verification, it will display a file (smime.p7s), which includes the X.509 certificate and the signature body. Read more at Certified E-Mail with Comodo and Thunderbird in AbiusX.com

On Mordad 4, 1392, at 11:47 AM, EnDe notifications@github.com wrote:

Why this check? There is no restriction anywhere to use HTTPS on port 80 or HTTP on port 443? This check does not comply to any defined standards, does it? (I mean standards like w3c, not common practice)

Sorry for bad news.

— Reply to this email directly or view it on GitHub.

[EnDe]

Hmm, I still do not get the point. All following is valid and not odd: https://abiusx.com:443/ https://abiusx.com:80/ http://abiusx.com:80/ http://abiusx.com:443/ https://abiusx.com:42/

Please don't break standards.

The odd ones are: https://abiusx.com/ http://abiusx.com/ 'cause they assume a specific server-side configuration (which is considered commom practice:)

[abiusx]

I think you're not getting it right. Its exactly the standard. Its human readable port, as present in the URLs. Nobody redirects you to example.com:80/somepage.php, but they do with 81. -Abbas

---

Notice: This message is digitally signed, its source and integrity are verifiable. If you mail client does not support S/MIME verification, it will display a file (smime.p7s), which includes the X.509 certificate and the signature body. Read more at Certified E-Mail with Comodo and Thunderbird in AbiusX.com

On Mordad 5, 1392, at 1:56 AM, EnDe notifications@github.com wrote:

Hmm, I still do not get the point. All following is valid and not odd: https://abiusx.com:443/ https://abiusx.com:80/ http://abiusx.com:80/ http://abiusx.com:443/ https://abiusx.com:42/

Please don't break standards.

The odd ones are: https://abiusx.com/ http://abiusx.com/ 'cause they assume a specific server-side configuration (which is considered commom practice:)

— Reply to this email directly or view it on GitHub.

[EnDe]

ok, please explain what I misunderstood.

[abiusx]

Its used for redirecting. Having the url: http://example.com:80/somepage.php in your browser doesn't look right, so for default cases (443 on HTTPS and 80 on HTTP), the human readable presentation of the port in the URL, is just an empty string. -Abbas

---

Notice: This message is digitally signed, its source and integrity are verifiable. If you mail client does not support S/MIME verification, it will display a file (smime.p7s), which includes the X.509 certificate and the signature body. Read more at Certified E-Mail with Comodo and Thunderbird in AbiusX.com

On Mordad 5, 1392, at 2:00 AM, EnDe notifications@github.com wrote:

ok, please explain what I misunderstood.

— Reply to this email directly or view it on GitHub.

[EnDe]

so you mean that the combination http :80 should be reduced to http amd https :443 to just https? That sounds reasonable. But why would you do that? It's not necessary, it does not give more security, does it?

[SvenRtbg]

But it avoids loosing for example cookies or javascript access because the original request was issued from "example.com" and the redirect takes you to "example.com:80", which is considered a different host by the browser.

[abiusx]

Its a practicum for safe redirects. Users trust URLs they are used to, and most URLs with a porn number in them look suspicious to most users. -A

---

Notice: This message is digitally signed, its source and integrity are verifiable. If you mail client does not support S/MIME verification, it will display a file (smime.p7s), which includes the X.509 certificate and the signature body. Read more at Certified E-Mail with Comodo and Thunderbird in AbiusX.com

On Mordad 5, 1392, at 2:07 AM, EnDe notifications@github.com wrote:

so you mean that the combination http :80 should be reduced to http amd https :443 to just https? That sounds reasonable. But why would you do that? It's not necessary, it does not give more security, does it?

— Reply to this email directly or view it on GitHub.

[abiusx]

I don't think it affects SOP by any means, the browser uses the host:port:path combination in cookie storage and doesn't look at the readable representation of it. -A

---

Notice: This message is digitally signed, its source and integrity are verifiable. If you mail client does not support S/MIME verification, it will display a file (smime.p7s), which includes the X.509 certificate and the signature body. Read more at Certified E-Mail with Comodo and Thunderbird in AbiusX.com

On Mordad 5, 1392, at 2:09 AM, SvenRtbg notifications@github.com wrote:

Am 26.07.2013 23:37, schrieb EnDe:

so you mean that the combination http :80 should be reduced to http amd https :443 to just https? That sounds reasonable. But why would you do that? It's not necessary, it does not give more security, does it?

---

Reply to this email directly or view it on GitHub: https://github.com/OWASP/phpsec/issues/30#issuecomment-21649732

But it avoids loosing for example cookies or javascript access because the original request was issued from "example.com" and the redirect takes you to "example.com:80", which is considered a different host by the browser. — Reply to this email directly or view it on GitHub.

[SvenRtbg]

Wikipedia states that stating the default port explicitly depends on the browser implementation, i.e. it might work or might not. I wouldn't take chances on this: If the port is the default port, do not make the port explicit.

[abiusx]

this is a valid point. Can you please check to see if someone has already covered this somewhere? We can be more sure that way, as a lot of folks are going to use this code. -A

---

Notice: This message is digitally signed, its source and integrity are verifiable. If you mail client does not support S/MIME verification, it will display a file (smime.p7s), which includes the X.509 certificate and the signature body. Read more at Certified E-Mail with Comodo and Thunderbird in AbiusX.com

On Mordad 5, 1392, at 2:40 AM, SvenRtbg notifications@github.com wrote:

Wikipedia states that stating the default port explicitly depends on the browser implementation, i.e. it might work or might not. I wouldn't take chances on this: If the port is the default port, do not make the port explicit.

— Reply to this email directly or view it on GitHub.

[EnDe]

AFAIK, cookie's SOP is independent of the port, but HTTP Authentication requires the port.

[abiusx]

We need someone to confirm this, its important.

---

Notice: This message is digitally signed, its source and integrity are verifiable. If you mail client does not support S/MIME verification, it will display a file (smime.p7s), which includes the X.509 certificate and the signature body. Read more at Certified E-Mail with Comodo and Thunderbird in AbiusX.com

On Mordad 5, 1392, at 10:23 AM, EnDe notifications@github.com wrote:

AFAIK, cookie's SOP is independent of the port, but HTTP Authentication requires the port.

— Reply to this email directly or view it on GitHub.

[EnDe]

Hmm, this is a check nobody wants to do, last reference I know of is from Michal Zalevski's BSH http://code.google.com/p/browsersec/wiki/Part3#HTTP_authentication it's 4 years old and also a bit sparce about the port being part of the realm. For cookies you can test yourself (and see the disaster we all know since ages;-) I doubt that browser do it much better today (as the RFCs didn't change).

Sorry for bad news and no solution. My advice for developers would be: don't mix schema, FQDN, and port, even you thinks it's the same (per standard or whatever). On the other side the advice for pentesters is: mix as much as possible and you find a way to break it.

[abiusx]

Unfortunately we don't get to lecture the developers that are going to use this, so lets make it as robust as possible. We need to add automated tests for this. SoP domain is very different from HTTP Auth, it has evolved too much in recent years, and every browser implements some security precautions of their own. -Abbas

---

Notice: This message is digitally signed, its source and integrity are verifiable. If you mail client does not support S/MIME verification, it will display a file (smime.p7s), which includes the X.509 certificate and the signature body. Read more at Certified E-Mail with Comodo and Thunderbird in AbiusX.com

On Mordad 5, 1392, at 9:14 PM, EnDe notifications@github.com wrote:

Hmm, this is a check nobody wants to do, last reference I know of is from Michal Zalevski's BSH http://code.google.com/p/browsersec/wiki/Part3#HTTP_authentication it's 4 years old and also a bit sparce about the port being part of the realm. For cookies you can test yourself (and see the disaster we all know since ages;-) I doubt that browser do it much better today (as the RFCs didn't change).

Sorry for bad news and no solution. My advice for developers would be: don't mix schema, FQDN, and port, even you thinks it's the same (per standard or whatever). On the other side the advice for pentesters is: mix as much as possible and you find a way to break it.

— Reply to this email directly or view it on GitHub.