ดังนั้นเราจึงมีเอกสารโกง XSSเพื่อทดสอบการกรอง XSS ของเรา - แต่นอกเหนือจากหน้าตัวอย่างที่ไม่เป็นอันตรายฉันไม่พบข้อมูลการทดสอบที่ชั่วร้ายหรือผิดรูปแบบเพื่อให้แน่ใจว่ารหัส UTF-8 ของฉันสามารถจัดการข้อมูลที่ผิดพลาดได้
จะหาข้อมูลดีๆมาทดสอบได้ที่ไหน หรือลำดับตัวอักษรที่ยุ่งยากคืออะไร?
~𝘈Ḇ𝖢𝕯٤ḞԍНǏ𝙅ƘԸⲘ𝙉০Ρ𝗤Ɍ𝓢ȚЦ𝒱Ѡ𝓧ƳȤѧᖯć𝗱ễ𝑓𝙜Ⴙ𝞲𝑗𝒌ļṃʼnо𝞎𝒒ᵲꜱ𝙩ừ𝗏ŵ𝒙𝒚ź1234567890!@#$%^&*()-_=+[{]};:'",<.>/?~ АḂⲤ𝗗𝖤𝗙 ꞠꓧȊ𝐉𝜥ꓡ𝑀𝑵Ǭ𝙿𝑄Ŗ𝑆𝒯𝖴𝘝𝘞ꓫŸ𝜡ả𝘢ƀ𝖼ḋếᵮℊ𝙝 Ꭵ𝕛кιṃդⱺ𝓅𝘲𝕣𝖘ŧ𝑢ṽẉ𝘅ყž1234567890! @ # $% ^ & * () -_ = + [{]}; : '", <.> /? ~Ѧ𝙱ƇᗞΣℱԍҤ١𝔍К𝓛𝓜ƝȎ𝚸𝑄Ṛ𝓢ṮṺƲᏔꓫ𝚈𝚭𝜶Ꮟçძ𝑒𝖿𝗀ḧ𝗂𝐣ҝɭḿ𝕟𝐨𝝔𝕢ṛ𝓼тú𝔳ẃ⤬𝝲𝗓1234567890!@#$%^&*()-_=+[{]};:'",<.>/?~ 𝖠Β𝒞𝘋𝙴𝓕ĢȞỈ𝕵ꓗʟ𝙼ℕ০𝚸𝗤 ՀꓢṰǓⅤ𝔚Ⲭ𝑌𝙕𝘢𝕤
คำตอบ:
ดูเพิ่มเติมได้อย่างไรว่าไฟล์ที่มีตัวอักษรจีนรู้จำนวนไบต์ที่ต้องใช้ต่ออักขระ? - ไม่ต้องสงสัยเลยว่ามีคำถาม SO อื่น ๆ ที่จะช่วยได้เช่นกัน
ใน UTF-8 คุณจะได้รับไบต์ประเภทต่อไปนี้:
Binary Hex Comments
0xxxxxxx 0x00..0x7F Only byte of a 1-byte character encoding
10xxxxxx 0x80..0xBF Continuation bytes (1-3 continuation bytes)
110xxxxx 0xC0..0xDF First byte of a 2-byte character encoding
1110xxxx 0xE0..0xEF First byte of a 3-byte character encoding
11110xxx 0xF0..0xF4 First byte of a 4-byte character encoding
(บรรทัดสุดท้ายดูเหมือนว่าควรอ่าน 0xF0..0xF7 อย่างไรก็ตามช่วง 21 บิตของ Unicode (U + 0000 - U + 10FFFF) หมายความว่าค่าที่ถูกต้องสูงสุดคือ 0xF4 ค่า 0xF5..0xF7 ไม่สามารถเกิดขึ้นได้ใน UTF-8 ที่ถูกต้อง)
การพิจารณาว่าลำดับไบต์เฉพาะเป็น UTF-8 ที่ถูกต้องหรือไม่หมายความว่าคุณต้องคิดถึง:
ใน UTF-8 ที่ถูกต้องไม่สามารถเกิดไบต์ 0xF5..0xFF ได้
มีการแสดงที่เป็นไปได้หลายอย่างสำหรับอักขระบางตัว ตัวอย่างเช่นอักขระ Unicode U + 0000 (ASCII NUL) สามารถแสดงโดย:
0x00
0xC0 0x80
0xE0 0x80 0x80
0xF0 0x80 0x80 0x80
อย่างไรก็ตามมาตรฐาน Unicode ระบุไว้อย่างชัดเจนว่าทางเลือกสามทางเลือกสุดท้ายไม่สามารถยอมรับได้เนื่องจากมีไม่น้อย มันจะเกิดขึ้นที่ไบต์ 0xC0 และ 0xC1 ไม่สามารถปรากฏใน UTF-8 ที่ถูกต้องได้เนื่องจากอักขระเพียงตัวเดียวที่สามารถเข้ารหัสโดยเหล่านั้นได้รับการเข้ารหัสน้อยที่สุดเป็นอักขระไบต์เดียวในช่วง 0x00..0x7F
ภายใน Basic Multi-lingual Plane (BMP) ค่า Unicode U + D800 - U + DFFF สงวนไว้สำหรับตัวแทน UTF-16 และไม่สามารถเข้ารหัสใน UTF-8 ที่ถูกต้องได้ หากถูกต้องใน UTF-8 (ซึ่งฉันเน้นว่าไม่ใช่) ตัวแทนจะถูกเข้ารหัส:
ดังนั้นข้อมูล BAD ของคุณควรมีตัวอย่างที่ละเมิดข้อกำหนดต่างๆเหล่านี้
โปรดทราบว่าเครื่องหมายลำดับไบต์ (BOM) U + FEFF หรือที่เรียกว่าช่องว่างที่ไม่มีความกว้างเป็นศูนย์ (ZWNBSP) ไม่สามารถปรากฏขึ้นโดยไม่ได้เข้ารหัสใน UTF-8 - ไม่อนุญาตให้ใช้ไบต์ 0xFF และ 0xFE ใน UTF-8 ที่ถูกต้อง ZWNBSP ที่เข้ารหัสสามารถปรากฏในไฟล์ UTF-8 เป็น 0xEF 0xBB 0xBF แต่ BOM นั้นไม่จำเป็นอย่างยิ่งใน UTF-8
นอกจากนี้ยังมีnoncharactersบางตัวใน Unicode U + FFFE และ U + FFFF เป็นตัวอักษรสองตัว (และสองจุดรหัสสุดท้ายในแต่ละระนาบ, U + 1FFFE, U + 1FFFF, U + 2FFFE, U + 2FFFF, ... U + 10FFFE, U + 10FFFF เป็นอื่น ๆ ). โดยปกติสิ่งเหล่านี้ไม่ควรปรากฏในข้อมูล Unicode สำหรับการแลกเปลี่ยนข้อมูล แต่สามารถปรากฏในการใช้งานส่วนตัว ดูลิงก์คำถามที่พบบ่อยของ Unicode สำหรับรายละเอียดที่ไม่ดีรวมถึงประวัติที่ค่อนข้างซับซ้อนของ noncharacters ใน Unicode ( Corrigendum # 9: Clarification About Noncharactersซึ่งเปิดตัวในเดือนมกราคม 2013 ทำในสิ่งที่ชื่อแนะนำ - ชี้แจงความหมายของอักขระที่ไม่ใช่ตัวอักษร)
คุณสามารถใช้เครื่องมือออนไลน์ที่มีประโยชน์นี้จาก Jeffrey Bergaminiเพื่อแปลงข้อความใด ๆ ให้เป็นสตริง Homoglyphs UTF8 ที่แปลกจริงๆ
โดยทั่วไป
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
กลายเป็นแบบนี้:
Ḽơᶉëᶆȋṕšᶙṁḍỡḽǭᵳʂǐťӓṁệẗ, ĉṓɲṩḙċťᶒțûɾ ấɖḯƥĭṩčįɳġḝłįʈ, șếᶑ ᶁⱺẽḭŭŝḿꝋďṫĕᶆᶈṓɍỉñḉīḑȋᵭṵńťṷŧḹẩḇőꝛếéȶđꝍꞎôꝛȇᵯáꞡᶇāąⱡîɋṹẵ.
บทความ UTF-8 ของ Wikipediaมีบทสรุปที่ดีว่าลำดับไบต์ใดถูกต้อง / ไม่ถูกต้อง บทความที่มีมูลค่าการอ่านก็คือW3C I18N คำถามที่พบบ่อย: แบบฟอร์มสื่อสารได้หลายภาษา
ปิดด้านบนของหัวของฉัน:
0xff และ 0xfe
ไบต์สูงบิตเดียว
การแทนค่าหลายไบต์ของอักขระแบบไบต์ต่ำ - วิธีที่ดีในการลักลอบนำค่าว่างจากการตรวจสอบก่อนกำหนด
เครื่องหมายไบต์ - คุณจะเพิกเฉยหรือไม่?