Report URI ใน X-XSS-Protection header ทำอะไรได้
คิดว่าหลายคนเข้ามาในนี้คงรู้จัก header ตัวนี้กันหมดแล้ว ข้ามส่วนอธิบาย header ไปเลยนะครับ
แต่หลายคนคงสงสัยว่า report คืออะไร ใน document เองก็เขียนไว้ไม่เยอะ
1; report=<reporting-URI> (Chromium only)อยากรู้ก็เลยลองเล่นเองง่ายๆ จัดไป localhost DVWA ใส่ header ให้เรียบร้อย อย่าลืม restart server จากนั้นก็เปิด nc -lvp 9080 รอไว้
ก็ตรงไปตรงมา เมื่อ browser ตรวจพบ reflected XSS จะส่ง report มาตาม path ที่เรา set ไว้ โดยมี JSON parameter ตามนี้
{"xss-report": {"request-url": "URL_of_XSS", "request-body": "Body_of_XSS"} }ทั้งหมดนี้ก็ขึ้นกับทีม monitoring ละ ว่าจะรับ report มาเก็บยังไง ทำอะไรบ้าง
พอดีเจอ service ให้ทดลองใช้ฟรี ก็เลยลองเล่นนิดๆหน่อยๆ
https://report-uri.com ลงทะเบียนแล้ว config ให้เรียบร้อย
แก้ตัว report ให้ยิงไปหา URL ที่บอกไว้ใน ReportURI แล้วก็ยิง XSS เลย โป้ง
ก็จะได้ report ออกมาละ ก็อย่างที่บอกไปคือ ขึ้นกับทีม monitoring ว่าจะจัดการมันยังไงบ้าง เก็บข้อมูลยังไง filter ยังไง แสดงยังไง
แต่แน่นอนว่า ถ้าสังเกตจาก request ที่ส่งมาเนี่ย มันไม่ได้มีการ authen อะไรเลยว่ามาจาก browser จริงๆ (และคงไม่มีวิธีด้วย) ดังนั้นเจอพวกยิงเล่นได้ เจอ false-positive นี่ มีแน่นอนครับ
อันนี้ก็ช่วยไม่ได้นะครับ กรองกันเอง
มีประโยชน์ไหม ส่วนตัวผมว่ามันก็… ไม่ค่อยมีนะ 555 คือ ผมหมายถึง
1. ถ้ามันติด XSS Auditor อยู่แล้ว ส่วนใหญ่มันก็จะโดนโจมตีไม่ได้อยู่แล้ว
2. เป็นการเพิ่ม attack surface ให้ระบบ
3. ถ้าบริษัทมี team monitor ได้ขนาดนี้แล้ว ก็ไม่ควรจะเหลือ reflected XSS เยอะๆนะ แปลว่า report ที่ได้มามันอาจจะน้อย จนไม่คุ้มค่า หรือจน filter ได้ยาก (อย่างที่บอก โดนยิงเล่นได้) ถ้า filter ยากจนไม่มีใครเข้าไปดูเนี่ย ก็ไปตกประเด็นข้อ 2 อีก คือมีไว้ทำไม…
4. support แต่ chrome และอนาคต XSS header นี้อาจจะถูกเอาออกทั้งยวงเลยด้วย 555 -..- ยิ่ง report นี่ไม่ค่อยมี web ไหนใช้กัน ตัว standard อาจจะไม่ค่อยแข็งแรงเข้าไปอีก มีใช้กันแค่ 7% เอง งืมๆ
มันมีประโยชน์แน่ๆครับ แต่อาจจะไม่คุ้ม effort ดังนั้นก็ลองพิจารณาให้เหมาะกับองค์กรของตัวเองนะครับ
ที่จริงมาลอง มาเขียนตอนนี้น่าจะช้าไป แต่ก็ให้จดจำไว้ว่าครั้งหนึ่งมันเคยมีอยู่บนโลกและมันก็ไม่ค่อยจะ work ละกัน 555
- July 18, 2019 -
