บทความ IT เจ๋งๆ

HTTP Headers นับเป็นเส้นทางที่ Server และ Client ใช้ในการส่งข้อมูลบางอย่าง ตัว Header เองไม่ใช่ Metadata แต่กลับเป็นตำแหน่งที่เก็บ Metadata มีหลายกรณีที่พวกมันสามารถถูกใช้แทน HTML และแม้แต่ JavaScript Code อีกทั้งเราสามารถปรับการ Config. ค่าให้เข้ากับ Environment ของเราและ Declare ครั้งเดียวแต่ใช้งานได้ทุกที่ และในบทความนี้จะกล่าวถึง HTTP Headers ที่ Web Developers ควรรู้จักและเชี่ยวชาญไว้

1. Strict-Transport-Security

ความปลอดภัยของ User Data เป็นสิ่งที่ต้องให้ความสำคัญอยู่เสมอ โดยเฉพาะอย่างยิ่งเมื่อมีการพยายามเข้าถึง Website ของเราผ่าน Public Network เมื่อใช้ Protocol HTTP ที่ไม่ปลอดภัย Browsers ส่วนใหญ่จะให้ชุดของ Warnings ต่าง ๆ ไว้ แต่อย่างไรก็ตาม สิ่งเหล่านั้นอาจไม่ได้รับความสนใจได้อย่างง่ายดาย

ด้วยการใช้ Strict-Transport-Security Response Header (ซึ่งมักใช้กันย่อ ๆ ว่า HSTS) เราจะสามารถบอก Browsers ได้อย่างชัดเจนว่า Site ของเราจำเป็นต้องมีการเข้ารหัส (Encryption) ซึ่ง Users จะถูก Force ให้ใช้ HTTPS Protocol หากต้องการดูการเข้าถึง

คำสั่ง: 

• max-age: นานแค่ไหนที่ควรจดจำ Header นี้ไว้ใน HSTS List
• includeSubdomains: ตั้งค่าสถานะเพื่อระบุว่า ควรจะส่งผลต่อ Subdomains ด้วย
• preload: มันควรถูกรวมอยู่ใน HSTS Preload List ของ Browser ด้วย มิฉะนั้น Browser จะไม่ได้รับการป้องกันจนกว่าจะมี Connection ที่ปลอดภัยเกิดขึ้นตั้งแต่ในครั้งแรก มันเป็น Feature ที่ถูกใช้ร่วมกันใน Browser หลัก ๆ คุณสามารถตรวจสอบได้ที่นี่ว่า Domain ของคุณได้รับการ Config. ค่ามาอย่างดีเพื่อรองรับสิ่งนี้หรือไม่

จากคำสั่งด้านบน จะช่วยให้เราปรับแต่งวิธีที่เราต้องการตั้งค่า HSTS Behavior ของเรา

มาดูตัวอย่างการใช้งานกัน:

ในตอนแรก การรวม Subdomains อาจยุ่งยากเล็กน้อย คำถามคือ แล้วคุณจะเลือกใช้และรวม Subdomains ให้ดีที่สุดได้อย่างไรบ้าง

เราสามารถเพิ่ม Strict-Transport-Security Response Header และเพิ่ม max-age ได้เรื่อย ๆ เราสามารถเริ่มต้นด้วยการเพิ่ม 2 minute ด้วย max-age=20 แต่หากทุกอย่างเรียบร้อยดี เราก็สามารถเพิ่มเป็น 1 สัปดาห์ด้วย max-age=604800 และ 1 เดือนด้วย max-age=2592000 หากทุกอย่างเป็นไปด้วยดี คุณสามารถตั้งค่าให้มีระยะเวลานานขึ้นเช่น 2 ปีหรือมากกว่านั้น

2. Content-Security-Policy

นี่เป็นหนึ่งใน Headers ที่สำคัญมากที่สุดตัวหนึ่งในแง่ของความปลอดภัย ซึ่งมันจะช่วยให้เรามีความละเอียดและ Config. ว่า Web Application ของเราจะจัดการ Resources อย่างไร มันให้เรากำหนดว่า Fonts, Content, Scripts ควรจะถูก Load และ Block อย่างไร ดังนั้นเราจึงสามารถ Block Scripts ที่เป็นอันตรายได้

มันสามารถถูก Config. ค่าใน DOM โดยใช้ <meta> Tag

การที่จะให้มีประสิทธิภาพเทียบเท่า Header นั้น เป็นเรื่องยากที่จะทำให้ถูกต้อง แล้วเราจะแน่ใจได้อย่างไรว่าเราตั้ง Rules ที่เข้มงวดเกินไป เนื่องจากเราไม่ต้องการที่จะทำอะไรที่ส่งผลเสียต่อ Website ของเรา

สำหรับสิ่งนั้น เราสามารถใช้ Header Content-Security-Policy-Report-Only ซึ่ง Header นี้จะเลียนแบบ Behavior ของ Content-Security-Policy แต่มันจะช่วย Warning เราเท่านั้น

ดังนั้น หากเราไม่ต้องการเพิ่มเติม Code พิเศษใด ๆ เข้าไปใน Website ของเรา เราสามารถ:

• ใช้ Content-Security-Policy ใน Stage/Production
• ใช้ Content-Security-Policy-Report-Only ใน Development Environments ของเรา ในการใช้สิ่งนี้ เราต้องใช้ report-uri เพื่อบอก Browser ว่า ควรส่ง Warnings ไปที่ใด

มีหลายสิ่งที่เราสามารถทำได้ด้วย CSP เรามาดู Security Features ที่สำคัญของมันกัน:

• ป้องกันตนเองจากการโจมตีแบบ Cross-Site Scripting
• Upgrade Connections เป็น HTTPS
• ป้องกันไม่ให้ Site ของเรา จากการแสดงผลภายใน Iframe
• จำกัดต้นทางจาก Images / Code / Media / Workers ...

สมมติว่าเราต้องการป้องกันไม่ให้ Page ของเราแสดงใน <iframe> เราสามารถทำได้ 2 วิธี:

มาดูตัวอย่าง CSP ที่สมบูรณ์กว่านี้กัน:

3. Referrer-Policy

เมื่อเราต้องการขับ Traffic ออกจาก Website ของเราด้วย Links ตัว Protocol จะเปิดเผยข้อมูลบางส่วนจาก Referring Site โดย Referrer-Policy Feature จะช่วยให้เราจัดการว่า เราควรจะรวมเอา Information อยู่ใน Outbound Requests เหล่านั้นมากน้อยแค่ไหน เราอาจมี User Sensible Data ซึ่งเราอาจไม่ต้องการที่จะ Share มัน

Referrer-Policy Feature มีอยู่ 3 ส่วน:

• เป็น meta tag:

• เป็น HTTP header:

• เป็น ใน a tag:

เราสามารถ Config. ค่าของ Information ได้อย่างละเอียดด้วย no-referrer, no-referrer-when-downgrade, origin, origin-when-cross-origin, same-origin, strict-origin, strict-origin-when-cross-origin และ unsafe-url

เราสามารถเลือกสิ่งที่เราจะเปิดเผยและผู้ที่เราจะเปิดเผยได้ วิธีนี้จะป้องกันไม่ให้ Web Applications ของเรามีการรั่วไหลของข้อมูล ไปยัง Sites อื่น ๆ

แล้วกลยุทธ์ที่ดีที่จะใช้กับ Features นี้คืออะไร เราสามารถควบคุม Application-Level Scoped Features ทั้งหมดได้ด้วย Feature-Policy Response Header แต่หากจำเป็น เราสามารถเพิ่มความละเอียดได้มากขึ้นโดยใช้ Referrerpolicy Anchor Element Attributes

สำหรับลำดับความสำคัญ จะถูกกำหนดตามลำดับดังนี้:

• Element-Level Policy
• Page-Level Policy
• Browser Default

4. Link

HTTP Link Header มี Mechanism แบบเดียวกันกับ <link> HTML Element มันช่วยกำหนดความสัมพันธ์ระหว่าง Document และ External Resource

ลองมาดู Syntax ของมันกัน:

มันอาจมีแค่ Link เดียว หรืออาจมีได้หลาย Links โดยเราจะใช้ , เพื่อแยก Links เหล่านั้น

เราสามารถใช้มันเพื่อ Config. ค่าสำหรับเพิ่ม Performance เช่น Preloading, Prefetching หรือ Pre-Connecting Resources

5. Feature-Policy

Feature Policy Mechanism Functionalities ไหนบน Web Application ของเราที่กำลังใช้งานอยู่ เราสามารถอนุญาตหรือปฏิเสธ Features ของ Browser ใน Frame ของตัวมันเองหรือเมื่อถูก Host ผ่าน iframe

มาดูกันว่ามันรองรับอะไรบ้าง

แล้วเราจะใช้มันได้อย่างไร เรามี 2 วิธีในการเลือกใช้ Feature นี้:

• allow Attribute บน <iframe> Element
• Feature-Policy HTTP Header

แม้ว่า allow Attribute จะมีการรองรับ Browser ได้ดีกว่า แต่มันก็สามารถควบคุม Features ได้เฉพาะที่ iframe level เท่านั้น ในการใช้ Header นั้น เราสามารถควบคุม Application และการใช้ iframe ด้วย: *, 'self', src (iframe allow attribute only), 'none', <origins(s)> allowlist

หมายเหตุ: HTTP Header นี้กำลังยังอยู่ในช่วงทดลองอยู่ มันถูกเปลี่ยนชื่อเป็น Permissions-Policy ใน Specs แต่ในที่สุดแล้ว ชื่อของมันอาจเปลี่ยนไปอีกก็ได้

ส่วนการใช้งานของมันก็ง่าย:

แล้วทำไม Header ถึงมีความสำคัญ มันช่วยรับรองความปลอดภัยเพิ่มเติมของ Web Application ของเรา เราสามารถบังคับใช้ Feature Rules ที่ app level เราสามารถตรวจสอบได้อย่างง่ายดายว่า ไม่มี 3^rd Party ที่กำลังใช้ Microphone ของเรา

แต่เราก็สามารถอนุญาตให้ใช้ Microphone จาก Domain ของเราเองเท่านั้น ดังนั้น หากมีใครที่ Embed Application ของเรา พวกเขาก็จะไม่สามารถใช้ Microphone ได้:

ที่มา: https://betterprogramming.pub/

 

 

รับตำแหน่งงานไอทีใหม่ๆ ด้วยบริการ IT Job Alert

 

อัพเดทบทความจากคนวงในสายไอทีทาง LINE ก่อนใคร
อย่าลืมแอดไลน์ @techstarth เป็นเพื่อนนะคะ

 

บทความล่าสุด

• 10 Open-Source DevOps Tools ที่มีประโยชน์อย่างเหลือเชื่อ
• 17 Python One-Liners ที่ช่วยทำงานซับซ้อน ให้ง่ายขึ้น
• 10 SQL Queries ที่ Data Scientist ควรทำความเข้าใจ