You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's assume that the IP whitelist contains only 1.2.3.4. When the attacker has his/her own name server, it can return two A records 5.6.7.8 and 1.2.3.4 for the requested domain. The current verification only checks if any of them matches to the whitelist, therefore it passes through the verification as 1.2.3.4 is in the whitelist. And alas, the first IP 5.6.7.8 gets used for rebuilding the URL.
Url::validateHost should really filter the IP lists returned by gethostbynamel according to the whitelist.
The text was updated successfully, but these errors were encountered:
That's a good point. DNS pinning has now been added, but like you mentioned, if only one IP is whitelisted, and the DNS pinning uses the other, then it could bypass the whitelist.
We've got two options for this. Check all IP's against the whitelist, and if all them don't match, throw an Exception.
The second is to only return whitelisted IP's (any which don't match the whitelist would be discarded). This would allow legit URL's, but could only be used where DNS pinning is enabled - else cURL could use the invalid IP.
I'm leaning toward the first option. What do you think?
Let's assume that the IP whitelist contains only
1.2.3.4
. When the attacker has his/her own name server, it can return two A records5.6.7.8
and1.2.3.4
for the requested domain. The current verification only checks if any of them matches to the whitelist, therefore it passes through the verification as1.2.3.4
is in the whitelist. And alas, the first IP5.6.7.8
gets used for rebuilding the URL.Url::validateHost
should really filter the IP lists returned bygethostbynamel
according to the whitelist.The text was updated successfully, but these errors were encountered: