
Summary: I found an issue similar to CVE-2022-42916 again. Since the phenomenon is the same, I will describe the same as last time. HSTS checks are bypassed if any character in the IDN convert(Nameprep) to a '.' for example"。"(UTF-8:E38082). I think there are other characters that become ".(UTF-8:2E)" as a result of converting with IDN. This is because the host name before IDN conversion is used when writing to the HSTS cache. Steps To Reproduce: [add details for how we can reproduce the issue] Start from a state where there is no entry for the access destination host name in the HSTS cache curl -v --hsts hsts.txt https://accounts.google%E3%80%82com curl -v --hsts hsts.txt http://accounts.google%E3%80%82com Result of 3. ``` C:\test\curl-7.86.0-win64-mingw\bin>curl -v --hsts hsts.txt http://accounts.google%E3%80%82com --head * Trying 142.250.206.237:80... * Connected to accounts.google縲Dom (142.250.206.237) port 80 (#0) HEAD / HTTP/1.1 Host: accounts.google.com User-Agent: curl/7.86.0 Accept: / ``` If you execute 3. after executing the below, you will access the site with HTTPS. curl -v --hsts hsts.txt https://accounts.google.com I use this in a Windows environment. I checked the HSTS cache after executing 2. and found the host name before IDN conversion. ``` Your HSTS cache. https://curl.se/docs/hsts.html This file was generated by libcurl! Edit at your own risk. .accounts.google。com "20231029 15:57:29" ``` I think the problem is in http.c:line 3727....
SOCIAL SHARE CARD GENERATOR