จุดประสงค์ของ @ (at symbol) ใน URL ก่อนโดเมนคืออะไร?
ฉันเพิ่งเจอการโจมตีแบบฟิชชิงแบบใหม่ซึ่งใช้@สัญลักษณ์เพื่อทำให้ URL ดูถูกต้อง มันจะเป็นแบบนี้:
ฉันมีบัญชีที่totally-legit-site.comและชุดการโจมตีค่าเว็บไซต์ฟิชชิ่งที่ IP 192.168.50.20ของเขาเหมือน http://[email protected]/accountจากนั้นเขาส่งข้อความมาที่เว็บไซต์มีการเชื่อมโยงซึ่งมีลักษณะเหมือน ใช้เพื่อหลอกให้ผู้ใช้คิดว่านี่คือลิงก์ไปยังไซต์ที่ถูกกฎหมาย
อย่างไรก็ตามการคลิกลิงก์นี้จะเปิดหน้า192.168.50.20/accountในเบราว์เซอร์ของฉัน (Google Chrome) ฉันพยายามเพิ่มสิ่ง@ที่สุ่มก่อนโดเมนแบบสุ่มและเบราว์เซอร์ของฉันแก้ไขหน้าเว็บอย่างถูกต้องเสมอโดยทิ้งสิ่งนั้น@ไป ถ้าลองเปิดดูhttp://[email protected]ก็จบที่หน้าแรกของ Google
สิ่งนี้ทำให้ฉันสนใจจริงๆ ฉันไม่พบข้อมูลใด ๆ เกี่ยวกับ@URL ก่อนโดเมน สิ่งนี้เรียกว่าอย่างไร? นี่เป็นสิ่งที่ล้าสมัยตั้งแต่ช่วงแรกของอินเทอร์เน็ตหรือไม่? มีเว็บเซิร์ฟเวอร์บางเว็บที่สามารถประมวลผลส่วนนี้ของ URL (ความสามารถในการแก้ไขอินสแตนซ์ nginx ของฉันเพื่อส่งคืนไซต์ต่างๆตามพารามิเตอร์นี้จะดีกว่า)
คำตอบ
ไวยากรณ์นี้ใช้เพื่อระบุรายละเอียดการรับรองความถูกต้องระดับโปรโตคอล (ชื่อผู้ใช้บางครั้งรหัสผ่านด้วย) สำหรับเชื่อมต่อกับ 'ผู้มีอำนาจ' ดูตัวอย่างRFC 3986 ส่วน 3.2.1
เมื่อใช้กับ HTTP ข้อมูลประจำตัวจะถูกส่งใน HTTP Authorization: header ; รูปแบบขึ้นอยู่กับกลไกการตรวจสอบสิทธิ์ที่เซิร์ฟเวอร์ร้องขอ แต่โดยทั่วไปแล้วการBasicตรวจสอบความถูกต้องจะใช้โดยไม่มีการประมวลผลเพิ่มเติม ดูRFC 7617หรือMDN
เว็บเซิร์ฟเวอร์จำนวนมากสามารถตรวจสอบข้อมูลประจำตัวกับ 'htpasswd' ไฟล์, LDAP, SQL หรือฐานข้อมูลอื่น ๆ - เช่นสำหรับ Nginx ดูauth_basicหรือ Apache httpd AuthType พื้นฐาน
หรืออีกวิธีหนึ่งการตรวจสอบสามารถทำได้โดย webapps เองเนื่องจากดำเนินการผ่านส่วนหัว HTTP มาตรฐานและรหัสสถานะ ดูตัวอย่างPHP (แต่เพื่อให้สามารถใช้งานได้ใน Apache คุณอาจต้องเปิดCGIPassAuthใช้งานหรือใช้เคล็ดลับการเขียนซ้ำแปลก ๆ มิฉะนั้นจะไม่ส่งต่อส่วนหัวการอนุญาตไปยังรันไทม์ของแอป)
การตรวจสอบสิทธิ์ HTTP ในตัวมักใช้สำหรับ API และคำขออัตโนมัติอื่น ๆ เนื่องจากไม่จำเป็นต้องมีการโต้ตอบกับผู้ใช้ไม่จำเป็นต้องจัดเก็บคุกกี้หรือสถานะอื่น ๆ และไม่จำเป็นต้องรู้วิธีจัดรูปแบบคำขอ POST "เข้าสู่ระบบ" (ซึ่งคุณ 'd ต้องการ <form> - จากการตรวจสอบสิทธิ์)
นี่เป็นวิธีการรับรองความถูกต้องเดียวกับที่ใช้โดยพร้อมต์เหล่านี้:
ไวยากรณ์เดียวกันนี้ยังใช้กับ FTP และโปรโตคอลอื่น ๆ อีกมากมายที่ใช้ URL และรองรับการพิสูจน์ตัวตน - ในทุกกรณีจะใช้กลไกในตัวของโปรโตคอลนั้น
การโจมตีที่นี่ทำงานได้เนื่องจากการตรวจสอบสิทธิ์ HTTP เป็นทางเลือกและในกรณีส่วนใหญ่ส่วนหัว HTTP พิเศษจะถูกละเว้นโดยเว็บเซิร์ฟเวอร์และเว็บแอป และในทางกลับกัน, เบราว์เซอร์ไม่ทราบว่าเซิร์ฟเวอร์จะถามสำหรับการตรวจสอบจนกระทั่งหลังจากที่ส่งคำขอ
อย่างไรก็ตามการโจมตีไม่ใช่เรื่องใหม่ที่ทุกคน - จะได้รับรอบตั้งแต่ในช่วงต้นยุค 2000 อย่างน้อย (ในความเป็นจริงในบางจุดเบราว์เซอร์ได้เริ่มตรวจสอบโดยก่อนอื่นให้ทำการร้องขอโดยไม่ต้อง auth เพื่อดูว่าเซิร์ฟเวอร์จะตอบกลับด้วย 401 หรือไม่หากเซิร์ฟเวอร์ไม่ร้องขอการตรวจสอบสิทธิ์ Chrome จะซ่อนชื่อผู้ใช้จากแถบที่อยู่เพื่อ โดเมนจริงชัดเจนมากขึ้นและ Firefox จะเตือนว่า "นี่อาจเป็นความพยายามที่จะหลอกลวงคุณ")