Defaults.Exposed › การแก้ไข › HSTS (Strict-Transport-Security)

วิธีแก้ไข HSTS (Strict-Transport-Security)

HSTS เป็นคำสั่งหนึ่งบรรทัดที่เว็บไซต์ของคุณให้กับทุกเบราว์เซอร์: 'กลับมาหาฉันเสมอผ่านการเชื่อมต่อที่ปลอดภัยและเข้ารหัส — ไม่ใช่การเชื่อมต่อที่ไม่ปลอดภัย' หากไม่มีมัน padlock ของคุณสามารถถูกดึงออกอย่างเงียบๆ บน WiFi สาธารณะ และการเข้าชมครั้งแรกของเว็บไซต์ของคุณถูกเปิดเผย

สรุปสำหรับธุรกิจของคุณ: การมี HTTPS (padlock) ไม่เหมือนกับการบังคับใช้มัน หากไม่มี HSTS ผู้โจมตีบน WiFi เดียวกับลูกค้าของคุณสามารถ downgrade การเชื่อมต่ออย่างเงียบๆ เป็น HTTP ธรรมดาที่ไม่ได้เข้ารหัส — จับ login รายละเอียดบัตรและข้อมูลแบบฟอร์มในขณะที่ลูกค้าไม่เห็นสิ่งผิดปกติ ใบรับรอง SSL ของคุณที่คุณอาจจ่ายเงินซื้อถูกข้ามไป การแก้ไขฟรีและใช้เวลาประมาณ 15 นาที

สิ่งนี้อาจทำให้คุณเสียค่าใช้จ่าย

• ลูกค้าบน WiFi ของร้านกาแฟ โรงแรม สนามบิน หรืองาน conference สามารถมีการเชื่อมต่อกับเว็บไซต์ของคุณ downgrade อย่างเงียบๆ และข้อมูลของพวกมันถูกอ่าน — โดยไม่มีคำเตือนบนหน้าจอของพวกมัน
• คุณจ่ายเงินสำหรับ HTTPS และมี padlock แต่หากไม่มี HSTS ผู้โจมตีสามารถ route รอบมันได้ง่ายๆ; ใบรับรองให้ความรู้สึกปลอดภัยที่เป็นเท็จ
• การเข้าชมครั้งแรกของเว็บไซต์ของคุณ (ก่อน redirect ใดๆ ไปยัง HTTPS) เป็นจุดอ่อนที่ผู้โจมตีเล็งเป้า — HSTS คือสิ่งที่ปิดมันสำหรับทุกการกลับเยี่ยมชม
• แบบสอบถามความปลอดภัย ฟอร์มประกันภัยไซเบอร์ หรือ checklist ของผู้ซื้อองค์กรทำเครื่องหมาย 'ไม่มี HSTS' และหยุดชะงักดีลจนกว่าจะแก้ไข
• ตั้งค่าผิด (สั้นเกินไป) และคุณได้รับสิ่งที่เลวร้ายที่สุดของทั้งสองโลก: มันดูเหมือนกำหนดค่าแล้วแต่ให้การป้องกันจริงแทบไม่มี

เหตุใดจึงสำคัญ HTTPS ปกป้องการเชื่อมต่อเมื่อเข้ารหัสแล้ว — แต่ไม่บังคับเบราว์เซอร์ให้ใช้มัน ผู้โจมตีใช้ช่องว่างนั้นด้วย 'SSL stripping': บนเครือข่ายสาธารณะใดๆ พวกมันเก็บผู้เข้าชมบน HTTP ที่ไม่ปลอดภัยอย่างเงียบๆ อ่านทุกอย่าง HSTS บอกเบราว์เซอร์ให้ปฏิเสธ HTTP ธรรมดาสำหรับโดเมนของคุณอย่างสมบูรณ์ เป็นเวลานาน เพื่อให้ช่องว่างปิดหลังจากการเข้าชมครั้งแรก มันเป็น response header เดียว ฟรีในการเพิ่ม และในการให้คะแนนของเราคุ้มค่าคะแนนจริงเพราะค่าที่หายไปหรือสั้นเกินไปทำให้ผู้เข้าชมทุกคนบน WiFi สาธารณะเปิดรับ

วิธีแก้ไข ทีละขั้นตอน

1. ให้บริการ HTTPS ที่ถูกต้องก่อน. HSTS มีความหมายเฉพาะเมื่อเว็บไซต์ของคุณโหลดอย่างถูกต้องผ่าน HTTPS ด้วยใบรับรองที่ถูกต้อง
2. เพิ่ม header. ส่ง Strict-Transport-Security: max-age=31536000; includeSubDomains บน HTTPS responses
3. เริ่มด้วย max-age ที่สั้นกว่า. ถ้าไม่แน่ใจ เริ่มด้วย max-age ที่เล็กกว่า ยืนยันว่า subdomain ยังทำงาน แล้วเพิ่มเป็นหนึ่งปี
4. พิจารณา preload. เมื่อ stable ด้วย includeSubDomains ให้เพิ่ม preload และส่งไปยัง browser preload list
5. ยืนยันว่ามันทำงาน. ตรวจสอบใหม่เพื่อยืนยันว่า header มีอยู่บน HTTPS responses

HSTS ในคำพูดง่ายๆ

คุณเกือบแน่นอนว่ามี HTTPS — padlock เล็กๆ ในแถบเบราว์เซอร์ ดี แต่นี่คือส่วนที่เกือบไม่มีใครได้รับแจ้ง: การมี HTTPS ไม่เหมือนกับการบังคับใช้มัน

HTTPS เข้ารหัสการเชื่อมต่อเมื่อเบราว์เซอร์ตัดสินใจใช้มัน HSTS — ย่อมาจาก HTTP Strict Transport Security — คือคำสั่งที่ทำให้เบราว์เซอร์ใช้มันเสมอ มันเป็นบรรทัดเดียวที่มองไม่เห็นที่เว็บไซต์ของคุณส่งให้ผู้เข้าชมทุกคนที่บอกว่าโดยหลัก:

“จากนี้เป็นต้นไปสำหรับโดเมนของฉัน ให้คุยกับฉันผ่านการเชื่อมต่อที่ปลอดภัยเท่านั้น ไม่ใช่การเชื่อมต่อที่ไม่ปลอดภัย อย่าแม้แต่พยายาม”

เบราว์เซอร์จำสิ่งนั้นและปฏิบัติตามตลอดเวลาที่คุณบอก — โดยทั่วไปหนึ่งปี หลังจากการเยี่ยมชมที่ปลอดภัยครั้งแรกของผู้เข้าชม เบราว์เซอร์ของมันจะปฏิเสธการโหลดเว็บไซต์ของคุณผ่าน HTTP ธรรมดาที่ไม่ได้เข้ารหัส แม้ว่าบางอย่างพยายามบังคับมัน

หากไม่มี HSTS กฎ “ใช้เวอร์ชันที่ปลอดภัยเสมอ” นั้นไม่มีอยู่ — และผู้โจมตีรู้ว่าจะใช้ช่องว่างได้อย่างไร

สิ่งนี้อาจทำให้คุณสูญเสียอะไร

เหล่านี้เป็นสถานการณ์จริงในชีวิตประจำวัน ภาพประกอบว่าช่องว่างถูกใช้อย่างไร

1. การ checkout ในร้านกาแฟ ลูกค้าเปิดร้านของคุณบน WiFi ของร้านกาแฟและไปชำระเงิน ผู้โจมตีบนเครือข่ายเดียวกันรันเครื่องมือฟรีที่รู้จักกันดีที่เก็บลูกค้าบน HTTP ธรรมดาแทน HTTPS ลูกค้าเห็นสิ่งที่ดูเหมือนเว็บไซต์ปกติของคุณ — ไม่มีคำเตือน ไม่มี padlock ที่แตกหักในจุดที่พวกมันจะมอง — และพิมพ์รายละเอียดบัตรของมัน ผู้โจมตีอ่านทุกการกดแป้น ใบรับรอง SSL ของคุณไม่ทำอะไรเลย เพราะการเชื่อมต่อไม่ได้รับอนุญาตให้กลายเป็นความปลอดภัยตั้งแต่แรก

2. พนักงานที่เดินทาง สมาชิกทีม log เข้า admin panel หรือ webmail ของคุณจากโรงแรมหรือสนามบิน เทคนิค downgrade เดียวกันจับ username และรหัสผ่านของพวกมัน ตอนนี้ผู้โจมตีมีทางเข้าสู่ธุรกิจของคุณ — ไม่ใช่เพราะนโยบายรหัสผ่านของคุณอ่อนแอ แต่เพราะหน้า login สามารถเข้าถึงได้ผ่าน HTTP ที่ไม่ปลอดภัย

3. ดีลที่หยุดชะงัก ลูกค้าขนาดใหญ่ส่งแบบสอบถามความปลอดภัยมาตรฐานของพวกมันก่อนเซ็นสัญญา บรรทัดหนึ่งถาม: “เว็บไซต์ของคุณบังคับ HTTPS ผ่าน HSTS ไหม?” ผู้ติดต่อ IT ของคุณต้องตอบว่า “ไม่” และกระบวนการจัดซื้อหยุดชะงักในขณะที่คุณรีบแก้ไข setting ฟรีที่ใช้เวลา 15 นาทีที่ตอนนี้ดูเหมือนเป็น red flag ต่อหน้าผู้ซื้อ

4. การตรวจสอบประกันภัยไซเบอร์หรือ compliance การสแกนของผู้ประกันภัย หรือผู้ตรวจสอบที่ทบทวนสถานะการป้องกันข้อมูลของคุณ ทำเครื่องหมาย header ที่หายไป การเข้ารหัสข้อมูลส่วนตัวเป็นความคาดหวังที่ชัดเจนภายใต้กฎการป้องกันข้อมูล (GDPR Article 32) และ “เรามีใบรับรองแต่ไม่บังคับใช้” เป็นที่ยืนที่อ่อนแอ

5. ความรู้สึกปลอดภัยที่เป็นเท็จ คุณจ่ายเงินสำหรับ SSL padlock แสดง และทุกคนสมมติว่าเว็บไซต์ปลอดภัย โดยส่วนใหญ่เป็นเช่นนั้น — จนกว่าลูกค้าจะอยู่บนเครือข่ายสาธารณะ ซึ่งเป็นช่วงเวลาที่พวกมันเสี่ยงมากที่สุดและมีโอกาสน้อยที่สุดที่จะสังเกตเห็นว่ามีอะไรผิดปกติ

สาย throughline: ค่าใช้จ่ายไม่เป็นนามธรรม มันคือบัตรหรือ login จริงของลูกค้าจริง ถูกจับในช่วงเวลาที่เลวร้ายที่สุดที่เป็นไปได้ โดยไม่มีสัญญาณเตือนดังขึ้น

มันคืออะไรจริงๆ

เมื่อเบราว์เซอร์ขอหน้าจากเว็บไซต์ของคุณ เซิร์ฟเวอร์ของคุณส่งคืนหน้านั้นพร้อมกับ “headers” ที่มองไม่เห็นบางส่วน — คำสั่งพิเศษที่เบราว์เซอร์อ่านแต่ผู้เข้าชมไม่เคยเห็น HSTS เป็นหนึ่งใน header เหล่านั้น:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

สามส่วนสำคัญ:

• max-age — ระยะเวลา (เป็นวินาที) ที่เบราว์เซอร์ควรจำเพื่อบังคับ HTTPS 31536000 คือหนึ่งปี นี่คือหัวใจของมัน: สั้นเกินไปและมันแทบไม่ช่วยอะไร
• includeSubDomains — ขยายกฎไปยังทุก subdomain (shop., app., mail. และอื่นๆ) ไม่ใช่แค่ที่อยู่หลักของคุณ
• preload — เลือกเข้าร่วมโดเมนของคุณในรายการหลักที่สร้างขึ้นในเบราว์เซอร์ เพื่อให้การป้องกันใช้แม้แต่กับคำขอแรกของผู้เข้าชม ก่อนที่พวกมันจะเคยเห็นเว็บไซต์ของคุณ

ทำไม “การเข้าชมครั้งแรก” ถึงสำคัญ

HSTS มีข้อจำกัดโดยธรรมชาติ: เบราว์เซอร์ปฏิบัติตามกฎหลังจากเห็น header อย่างน้อยครั้งหนึ่ง ดังนั้นการเชื่อมต่อครั้งแรกของผู้เข้าชมใหม่ยังคงเป็นหน้าต่างเล็กๆ ของการเปิดเผย สองสิ่งลดขนาดมัน: redirect จาก HTTP เป็น HTTPS (ซึ่งนำพวกมันไปยังเวอร์ชันที่ปลอดภัยอย่างรวดเร็ว) และ preload (ซึ่งลบหน้าต่างออกอย่างสมบูรณ์) นั่นเป็นเหตุผลที่การตั้งค่าที่สมบูรณ์จับคู่ HSTS กับ redirect ที่เหมาะสม

”ดี” ดูเหมือนอะไร — และมันถูกให้คะแนนอย่างไร

การตรวจสอบของเราอ่าน header สด และให้คะแนน max-age:

ดังนั้น header ที่มีอยู่แต่ตั้งค่าเป็นสองสามนาทีถูกถือว่าล้มเหลว — มันดูกำหนดค่าแต่ไม่ได้ทำงาน มุ่งหาหนึ่งปี การตรวจสอบยังสังเกตว่า includeSubDomains และ preload มีอยู่หรือไม่

วิธีแก้ไข (ฟรี ~15 นาที)

ส่งส่วนนี้ให้ผู้ที่ดูแลเว็บไซต์ของคุณ — ผู้ดูแลระบบ IT, นักพัฒนาเว็บ หรือ hosting support การแก้ไขฟรี มันเป็น header เดียว หรือ toggle ในแพลตฟอร์ม hosting ของคุณ ไม่มีอะไรต้องซื้อ

กฎการเรียงลำดับที่สำคัญหนึ่งข้อก่อน: HSTS เหนียว — เมื่อเปิดใช้งาน เบราว์เซอร์จะปฏิเสธ HTTP ธรรมดาสำหรับโดเมนของคุณตลอด max-age เต็ม ดังนั้นยืนยันว่า HTTPS ทำงานอย่างถูกต้องบนเว็บไซต์หลักและทุก subdomainก่อนเปิดใช้งานอย่างกว้างขวาง เส้นทางที่ปลอดภัยคือ: ทดสอบด้วยค่าสั้น → ยืนยันว่าไม่มีอะไรเสียหาย → เพิ่มเป็นหนึ่งปี

ขั้นตอนที่ 1 — ตรวจสอบให้แน่ใจว่า HTTPS ทำงานได้ทุกที่แล้ว

เยี่ยมชมเว็บไซต์ของคุณและ subdomain หลักผ่าน https:// และยืนยันว่าพวกมันโหลดสะอาดด้วยใบรับรองที่ถูกต้อง ยืนยันด้วยว่าคำขอ http:// ธรรมดา redirect ไปยัง https:// (ถ้าไม่ แก้ไข redirect จาก HTTP เป็น HTTPS ก่อน — HSTS สมมติว่ามันอยู่ในที่)

ขั้นตอนที่ 2 — เพิ่ม header (เลือกแพลตฟอร์มของคุณ)

Cloudflare (หรือ CDN ที่คล้ายกัน): นี่ง่ายที่สุด ไปที่ SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) และเปิดใช้งาน ตั้ง Max-Age เป็น 6 เดือนหรือ 12 เดือน และเปิด “Apply HSTS policy to subdomains” เมื่อคุณแน่ใจว่า subdomain ทั้งหมดอยู่บน HTTPS

Nginx: เพิ่มใน HTTPS server block:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Apache: ตรวจสอบให้แน่ใจว่า mod_headers เปิดใช้งาน จากนั้นเพิ่มไปยัง HTTPS virtual host:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Microsoft IIS: เพิ่มไปยัง web.config ใน <customHeaders>:

<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />

บันทึก Google Workspace / Microsoft 365: สิ่งเหล่านี้ขับเคลื่อนอีเมลของคุณ ไม่ใช่ website hosting — HSTS ถูกตั้งค่าที่ใดก็ตามที่เว็บไซต์สาธารณะของคุณอยู่จริง (CDN, web server หรือ site builder) ไม่ใช่ใน Workspace/365 admin ถ้าเว็บไซต์ของคุณอยู่บน builder เช่น Squarespace, Wix หรือ Shopify HSTS มักจัดการให้คุณ; ตรวจสอบการตั้งค่า SSL/ความปลอดภัยของพวกมันถ้าการตรวจสอบของเราทำเครื่องหมายมัน

ขั้นตอนที่ 3 — ทดสอบเล็กน้อย แล้วยืนยัน

เริ่มด้วย max-age=300 (5 นาที) ยืนยันว่าเว็บไซต์ยังโหลดอย่างสมบูรณ์ทุกที่ จากนั้นเพิ่มเป็น max-age=31536000 (หนึ่งปี) นั่นคือการตั้งค่าที่ได้คะแนนเต็ม

ขั้นตอนที่ 4 (ตัวเลือก มาตรฐานทอง) — preload

เมื่อคุณมั่นใจและรัน header หนึ่งปีกับ includeSubDomains สักพัก คุณสามารถส่งโดเมนที่ hstspreload.org เพื่ออบลงในเบราว์เซอร์ สิ่งนี้ปิดหน้าต่างการเข้าชมครั้งแรกอย่างสมบูรณ์ ถือว่ามันเป็นความมุ่งมั่นที่ตั้งใจ — การลบโดเมนออกจากรายการช้า

ข้อผิดพลาดทั่วไป

• ตั้ง max-age สั้นเกินไป ค่าสองสามนาทีหรือชั่วโมงดูกำหนดค่าแต่ให้การป้องกันแทบไม่มี — และการตรวจสอบของเราถือว่าสิ่งที่น้อยกว่าหนึ่งวันเป็นการล้มเหลว ใช้หนึ่งปี
• เปิด includeSubDomains ก่อนที่ subdomain พร้อมด้วย HTTPS ถ้า subdomain ไม่ได้อยู่บน HTTPS อย่างเต็มรูปแบบ กฎเหนียวสามารถทำให้มันไม่สามารถเข้าถึงได้สำหรับผู้เข้าชม นำ subdomain ทุกตัวไปยัง HTTPS ก่อน
• เพิ่ม HSTS แต่ไม่มี redirect จาก HTTP เป็น HTTPS HSTS สมมติว่าผู้เข้าชมถึงเวอร์ชันที่ปลอดภัย หากไม่มี redirect การเข้าชมครั้งแรกเปิดรับโดยไม่จำเป็น แก้ไขทั้งสองพร้อมกัน
• กระโดดไปที่ preload โดยตรงเพื่อ “ทำให้ครอบคลุม” Preload ยากที่จะยกเลิก รับมันหลังจาก header หนึ่งปีที่ stable — อย่ารีบ
• สมมติว่า padlock หมายความว่าคุณได้รับการครอบคลุมแล้ว padlock และ HSTS เป็นสิ่งที่แตกต่างกัน คุณสามารถมีใบรับรองที่สมบูรณ์แบบและยังล้มเหลวการตรวจสอบนี้

คำถามที่พบบ่อย