ก่อนหน้านี้กูเกิลประกาศเพิ่มโดเมนระดับใหญ่สุดหรือ Top-Level Domain (TLD) เพิ่มเติมอีก 8 ชื่อ ได้แก่ .dad, .esq, .prof, .phd, .nexus, .foo และอีกสองชื่อที่เป็นประเด็นในข่าวนี้คือ .zip และ .mov

โดยผู้เชี่ยวชาญและนักวิจัยความปลอดภัยไซเบอร์หลายคน แสดงความกังวลว่าชื่อ zip และ mov นี้ อาจถูกใช้จดเป็นโดเมนเพื่อทำเว็บฟิชชิ่งหรือฝังมัลแวร์ได้ เนื่องจากสามารถทำให้ผู้ใช้งานสับสนง่าย ทั้งนี้โดเมน .zip และ .mov ได้รับการอนุมัติให้ใช้งานได้ตั้งแต่ปี 2014 แต่เพิ่งเปิดให้สมัครจดโดเมนได้ทั่วไปเมื่อต้นเดือนที่ผ่านมา

หลังจากรอคอยมานานแสนนาน......(ไม่ใช่แล้ว) ที่ล้ออันนี่เนื่องมาจากว่ากำหนดการออกเอกสาร "10 อันดับความเสี่ยงสูงสุดของเว็บแอพพลิเคชัน" ซึ่งเกิดจากการรวบรวมขอข้อมูลจากบริษัทต่าง ๆ โดยจะสรุปออกมาเป็นความเสี่ยง (ช่องโหว่) นั้นมีกำหนดจะต้องออกภายในปี 2016 แต่โดนโรคเลื่อนจนมาถึงปี 2017 โดยเอกสารที่ออกมาตอนนี้ก็ยังไม่ใช่ version เต็มเพราะฉะนั้นรายละเอียดอาจจะมีเปลี่ยนเล็กน้อย แต่เรื่องอันดับนี่ไม่น่าจะมีเปลี่ยนแล้วแน่นอน

กระบวนการรับรอง SSL/TLS Certificate หรือ “ใบรับรองอิเล็กทรอนิกส์” (ต่อไปจะเรียกว่า TLS Certificate) จะผ่านทาง Certificate Authority หรือ “ผู้ออกใบรับรองอิเล็กทรอนิกส์” (CA)

โดยเว็บเบราว์เซอร์หรือระบบปฏิบัติการ (ต่อไปจะเรียกว่า client) จะมีรายการที่เรียกว่า Trusted Root Certification Authorities หรือ “รายการใบรับรองอิเล็กทรอนิกส์ของผู้ออกใบรับรองอิเล็กทรอนิกส์สำหรับผู้อื่น” อยู่ภายใน โดยมากมักอ้างอิงกับตัวระบบปฏิบัติการเป็นหลัก ซึ่งจะบรรจุ Root Certificate หรือ “ใบรับรองอิเล็กทรอนิกส์ลำดับชั้นบนสุด” เพื่อให้ client สามารถเชื่อใบรับรองอิเล็กทรอนิกส์ที่ได้รับรองจาก Certificate Authority เหล่านั้น (Trust any certificates issued by the Certificate Authorities)

ช่องโหว่ CSRF เป็นช่องโหว่สำคัญที่เว็บจำนวนมากที่ไม่ได้พัฒนาจาก CMS ดังๆ มักถูกโจมตีได้เรื่อยๆ จาก ล่าสุดกูเกิลกำลังทดสอบและเสนอมาตรฐาน First-Party-Only จำกัดการส่งคุกกี้ในกรณีที่เว็บถูกเรียกจากโดเมนอื่นๆ

ปัญหา CSRF คือ แม้เว็บหนึ่งๆ จะไม่สามารถอ่านข้อมูลจากเว็บอื่นๆ ได้ เช่น ในกรณีที่ผู้ใช้ Blognone ล็อกอิน YouTube อยู่และมีวิดีโอฝังอยู่ในข่าว หน้าเว็บ Blognone ก็ไม่สามารถเขียนสคริปต์เพื่ออ่านข้อมูลของ YouTube อย่างชื่อผู้ใช้ออกมาได้ อย่างไรก็ดีหน้าเว็บ Blognone อาจจะขอแสดง URL โดยที่อ่านค่าไม่ได้ เช่น URL สำหรับลบวิดีโอล่าสุด หากผู้ใช้ล็อกอินทิ้งไว้และเว็บไม่ได้ป้องกัน คำสั่งก็จะมีผลทันที

อัพเดต: ทาง McDonald's แก้ไขเรียบร้อยแล้วครับ

มีรายงานจาก @nuuneoi หรือคุณสิทธิพล พรรณวิไล นักพัฒนาแอพพลิเคชั่นบนโทรศัพท์มือถือว่าเว็บ McDonald ประเทศไทย (www.mcthai.co.th) ถูกแฮก และ redirect ผู้ใช้ไปยังหน้าดาวน์โหลดแอพพลิเคชั่น

ผมตรวจสอบดูพบว่าหน้าดาวน์โหลดนี้จะทำงานต่อเมื่อเข้าเว็บผ่านโทรศัพท์มือถือเท่านั้น และเมื่อถูก redirect ไปแล้ว หากใช้โทรศัพท์แอนดรอยด์ จะสามารถกดดาวน์โหลด Mobile_Version.apk มาลงเครื่องได้ แต่หากใช้อุปกรณ์ iOS เมื่อกดดาวน์โหลดก็จะถูก redirect ไปยังหน้าเว็บกูเกิลแทน

ระหว่างนี้ผมยังไม่สามารถตรวจสอบได้ว่าไฟล์ Mobile_Version.apk นี้ทำอะไรกับเครื่องบ้าง ก็เตือนทุกท่านว่าห้ามติดตั้งไฟล์แบบนี้เด็ดขาดครับ

Google ประกาศปรับอัตราเงินรางวัลสำหรับผู้แจ้งช่องโหว่ของเว็บเพิ่มขึ้นหลังจากที่เพิ่งปรับอัตราการจ่ายเงินรางวัลไปเมื่อไม่กี่เดือนก่อน

Google ได้ปรับเกณฑ์การให้รางวัลสำหรับผู้ค้นพบช่องโหว่โดยการทำ XSS (cross-site scrpting) ซึ่งเป็นการฝังโค้ดเข้าไปในหน้าเว็บไซต์ที่มีช่องโหว่นั้นเพื่อดักจับข้อมูลสำคัญในระหว่างที่ผู้ใช้งานเปิดเข้าใช้หน้าเว็บไซต์ดังกล่าว

บั๊กใน Roby on Rails ที่ใช้โมดูล XML parameter เพื่อรับค่าพารามิเตอร์ในการโพสแบบ XML กำลังทำให้เว็บไซต์ที่รัน Ruby on Rails แทบทั้งหมดเจอปัญหา remote code execution หรือการรันโค้ดที่รับมาจากผู้ใช้

ปัญหาเกิดจากโมดูลสำหรับ parse XML นั้นรองรับค่าชนิด symbol และ yaml โดยโครงสร้างความปลอดภัยของภาษา Ruby นั้นไม่ควรให้ค่า symbol ถูกส่งมาจากภายนอกได้ รวมถึงค่าของ yaml นั้นสามารถใช้รันโค้ดบางส่วนได้โดยโครงสร้างของมันเอง จึงไม่ควรนำมาใช้รับค่าจากผู้ใช้ภายนอก

เว็บไซต์ที่ใช้ Ruby on Rails ทั้งหมด (มากกว่า 240,000 เว็บไซต์ทั่วโลก) ควรแพตซ์โค้ดที่ใช้งานอยู่เพื่อยกเลิกการรับค่าแบบ XML ออกไป หรือไม่เช่นนั้นอาจจะอัพเกรดโค้ดไปยังเวอร์ชั่นล่าสุด

นิตยสาร PC World ได้ทำการจัดอันดับช่องโหว่ที่ใช้ในการจู่โจมเว็บไซต์เมื่อปี 2010 ที่ผ่านมา โดยทั้ง 10 อันดับนี้จะถูกโหวตจากผู้เชี่ยวชาญและจากบุคคลทั่วไป (Open Vote)

ช่องโหว่ทั้ง 10 จัดอันดับได้ดังต่อไปนี้

1. Padding Oracle Crypto Attack: อาศัยช่องโหว่จาก Microsoft's Web Framework ASP.NET ที่ใช้ในการป้องกัน AES encryption Cookies ได้ซึ่งถ้าตัวข้อมูลของ Cookies ที่เข้ารหัสถูกเปลี่ยนแปลงตัว ASP.NET ที่ทำการดูแลข้อมูลพวกนี้อยู่จะหลุดข้อมูลบางอย่างซึ่งสามารถถอดรหัสข้อมูลได้ ด้วยจำนวนครั้งในการเปลี่ยนที่มากพอ แฮคเกอร์สามารถคาดเดาคีย์ที่ใช้ในการเข้ารหัสได้ง่ายขึ้น (โดย Juliano Rizzo และ Thai Duong)