07 มิถุนายน 2560

Software Security Requirement Guideline กับการปล่อยไก่ของผม

เรื่องเล่ายามดึก
ตอนเข้ามาเกียรตินาคินใหม่ๆ ได้เขียน Software Security Requirement Guideline ฉบับหนึ่งเพื่อให้ทาง Development Team และ Vendor ทำตาม โดยอ้างอิงจากเอกสารของ OWASP ฉบับหนึ่ง (ซึ่งเดี๋ยวจะบอกทีหลัง) เป็นหลัก โดยมีการปรับแก้เพิ่มเติมบางอย่างตาม IT Policy ของธนาคาร และ Industrial Standard และ Regulation เช่น PCI-DSS หรือ Best Practice ของธนาคารแห่งประเทศไทยเข้าไป (ซึ่งไม่ได้มากมายเพราะส่วนใหญ่ของ OWASP จะดีกว่าอยู่แล้ว)
หลังจากนั้นเอกสารฉบับนี้ก็มีการรวมร่างกับ Software Architecture Requirement กลายเป็น Software Security and Architecture Guideline ล่าสุดคือ Version 4 และผมก็ไม่ได้เขียนเองแล้ว แต่เป็นคน Review
ตัดกลับมาเมื่อคืนวาน น้องในกลุ่ม OWASP บอกว่าหาคนไปพูดเรื่อง
ASVS ในงาน Thailand Security Day อะไรสักอย่างที่ ETDA วันที่ 26 มิถุนายน ผมก็บอกว่า ASVS คืออะไร ไม่เคยได้ยิน สักพักก็มีการส่ง Link ของเอกสารมาให้ เปิดไปดูก็เห็นเขียนว่า OWASP Application Security Verification Standard 3.0.1 (July 2016) เราก็อืม มันเป็นตัวย่อนี่เอง นั่งอ่านไปสักพักก็รู้สึกว่าคุ้นๆ แฮะ นึกไปนึกมาก็จำได้ว่าเราเคยใช้รายการในเอกสารฉบับนี้เขียน Software Security Guideline ของธนาคาร กลับไปเช็คดู เฮ้ย เราใช้ Version 2.0 เป็นต้นฉบับนี่นา
ด้วยอารมณ์ที่คิดว่าต้อง Update รายการให้ทันสมัยเลยส่ง Link ไปให้น้องในทีมที่ดูแลเอกสารต่อ บอกว่าเราต้อง Update ให้กับเอกสาร Software Security and Architecture Guideline แล้วล่ะ
วันนี้น้องในทีมมาบอกว่า พี่ ผมใช้เอกสารของ OWASP ฉบับนี้มาแก้เอกสารของเราในเวอร์ชันปัจจุบันแล้วนะ พี่เป็นคนรีวิวเองด้วย
ไก่วิ่งเต็มที่ทำงาน จับแทบไม่ทัน

02 ธันวาคม 2559

เรามาเขียนโค้ดได้ไง

ไม่แน่ใจว่าชัยพฤกษ์วิทยาศาสตร์หรือเซมิคอนดักเตอร์อิเลคทรอนิคส์ทำให้เราได้รู้จักกับ Apple ][ กับภาษา Basic เริ่มเขียนโค้ดครั้งแรกตอน ม.3 แต่เขียนบนกระดาษ ไม่มีคอมพิวเตอร์ให้ใช้เพราะอยู่ต่างจังหวัด กว่าจะได้ใช้ครั้งแรกก็ตอนอยู่ม.4 เพราะเข้ามาเรียนกรุงเทพ ตอนเปลี่ยนมาเป็น MS Windows ใช้หากินจาก VB และ VBA อยู่พักใหญ่
ภาษาที่สองที่เขียนเป็นคือ Assembly บน 6502 โดยได้หนังสือสามจากร้าน Book Chest แถวสยาม ไม่มี Assembler ใช้วิธีเปิดตาราง Opcode เอา แล้วโปรแกรมเป็น Hexadecimal เข้าไปบนเครื่อง Apple ][ ของเพื่อน ต่อมาจึงขยับขยายเป็น Z-80, 8048, 8086 และ MCS-51
ภาษาที่สามเป็น Lego เรียนตอนม.4ที่เตรียม สนุกดี แต่ไม่มีสาระ ลืมไปแล้วด้วย
ภาษาที่ 4 คือ FORTRAN เรียนตอนปีหนึ่ง ชอบที่จัดการ Matrix และ Imaigantion Numberได้
ภาษาที่ 5 ที่เขียนได้คือ C โดยได้หนังสือชื่อ ปอกส้มเข้าปาก ที่แถมมาจากวารสารคอมพิวเตอร์ฉบับหนึ่ง ลองหัดเขียนโดยใช้ Microsoft C ซึ่งเป็น Command Line Compiler แล้วจึงย้ายมาใช้ Turbo C เพราะเป็น IDE รุ่นแรกๆ บน MSDOS ชอบเพราะสั้นและทำ Bitwise Operation ได้เหมือน Assembly ตอนนี้ชำนาญเป็นอันดับหนึ่ง
ภาษาที่ 6 คือ Pascal โดย Turbo Pascal ไม่ชอบภาษานี้เพราะเยิ่นเย้อ ไม่ชอบการแยก Procedure กะ Function
ภาษาที่ 7 คือ C++ อ่านตอนอยู่ปี 1 แต่ไม่เชี่ยวชาญมาก มาเชี่ยวตอนเล่น Linux กะเขียนโปรแกรมลง Microsoft Pocket PC เลยเถิดมาบน ARM Embeded System เชี่ยวเป็นลำดับที่ 2
ภาษาที่ 8 คือ COBOL ตอนเรียนภาคคอม ลืมไปแล้ว
ภาษาที่ 9 คือ Java ตอนที่ออกใหม่ๆ เขียน Applet บน Web หลังๆ พอมาดังบน J2EE แล้วก็ไม่ค่อยได้เขียน
ภาษาที่ 10 คือ JavaScript เพราะต้องเขียน Web Page ให้มีลูกเล่น เป็นเหตุให้ต้องเรียนรู้ DOM ในเวลาต่อมา
ภาษาที่ 11 คือ VBScript บน ASP Classic ที่ออกมาพร้อม IIS 3 เป็น Server Side Scripting แรกที่หัด
ภาษาที่ 12 คือ PHP ตอนเขียน Web Server Component Linux ช่วงแรกๆ แต่ก็เลยเถิดมาไกล ใช้เยอะมากจนถนัดเป็นอันดับสาม รู้ไส้รู้พุงดีว่า Security มันเป็นไง
ภาษาที่ 13 คือ Python ไม่เชี่ยวแต่เขียน GUI ได้ก็แล้วกัน มาหัดตอนอยู่ที่เกียรตินาคินเพราะเห็น exploit code ส่วนใหญ่มันเป็น Python

ภาษาที่เป็นแต่ไม่นับก็คือพวก Shell Script เช่น Perl, DOS/Windows Batch, Bash
C# ไม่นับเพราะมันเป็นลูกหลานของ C++
ไม่นับพวก Markup Language แล้วกัน เอาแต่ Programming Language
ว่าจะหัด Ruby เหมือนกันเพราะ Metasploit แต่ตอนนี้ยุ่งเกินกว่าจะหัดใหม่

ไขข้อข้องใจว่าทำไมผมทำ Secure Code Review ได้

26 พฤษภาคม 2559

Data Quality in Data Warehouse


วันนี้ได้มีโอกาสคุยกับ CIO เกี่ยวกับเรื่องการทำระบบ Customer Relationship Management (CRM) ของธนาคาร ซึ่งหัวข้อการสนทนารวมไปถึงการได้มาของข้อมูล ความถูกต้องของข้อมูล การใช้ขัอมูลแบบ Big Data รวมถึงมาตรฐานเกี่ยวกับประเภทข้อมูล

สิ่งที่ได้รับจากการสนทนาพบว่าตัวเองมองข้อมูลใน Data Warehouse ไม่ครบทุกมุมมอง เนื่องจากไม่ได้อยู่ใน Financial Sector มาก่อนหน้านี้เลยมอง Data Warehouse เพียงเพื่อตอบสนองความต้องการข้อมูลเพื่อไปใช้ในเชิงการตลาดและ CRM แต่เพียงอย่างเดียว ซึ่งข้อมูลที่ใช้เชิงนี้ไม่ได้ต้องการความแม่นยำของข้อมูล (Precision) ในระดับที่สูง เพียงแค่ต้องการความครบถ้วนเพื่อใช้ในการวิเคราะห์ตามสมมติฐานทางการตลาดที่ตั้งขึ้น หรือหา Insight

แต่ข้อมูลใน Data Warehouse ของ Financial Sector ต้องการความแม่นยำของข้อมูลที่สูงเพื่อนำไปใช้ตามกฏระเบียบ (Regulation) ด้วย เช่น Basel, SOX เป็นต้น อย่างไรก็ตามข้อมูลชุดนี้ก็นำไปวิเคราะห์ในเชิงการตลาดด้วยเช่นพวก Financial Transaction เป็นต้น

ปัญหาของ Data Quality ใน Data Warehouse จึงอยู่ที่ว่าผู้ที่ดูแลข้อมูลให้ครบถ้วนมักจะโอนเอียงไปด้านใดด้านหนึ่งคือ เพื่อ Regulation หรือเพื่อ Analytic หายากมากที่จะคำนึงถึงข้อมูลที่ตอบสนองต่อทั้งสองด้านได้ไปพร้อมๆ กัน ในสถาบันการเงินส่วนใหญ่จึงมุ่งไปทำให้ Data Quality เกิดขึ้นเพื่อด้าน Regulation

ถ้าอย่างนั้นแล้วข้อมูลที่ใช้สำหรับทำ Data Analytic ทางสถาบันการเงินจะเตรียมข้อมูลที่มีคุณภาพเข้าสู่ Data Warehouse อย่างไร สำหรับสถาบันการเงินที่มีงบประมาณในการทำ Data Warehouse มากก็คงกวาดเอาข้อมูลให้มีประเภทของข้อมูลเข้าไปมากที่สุดไว้ก่อน มีคุณภาพหรือไม่ว่ากันทีหลัง แต่สำหรับสถาบันการเงินที่ไม่ได้มีงบประมาณมากขนาดนั้นคงต้องคัดกรองประเภทและคุณภาพของข้อมูลเพื่อให้การวิเคราะห์ทำได้ดีที่สุด

ความยากคงอยู่ที่ข้อมูลประเภทใด Field ไหน Transform อย่างไรที่ควรเข้าไปอยู่ใน Data Warehouse อย่างมีคุณภาพในสภาพที่มีทรัพยากรจำกัดเพื่อการวิเคราะห์ได้เกิดประโยชน์สูงสุด

09 กุมภาพันธ์ 2559

Secure Software Design 101: Fail-Safe / Fail-Secure

ในการออกแบบด้าน Security ต้องมีการคำนึงถึงสถานการณ์ที่ไม่พึงประสงค์ที่อาจเกิดขึ้นเนื่องจากความผิดพลาด อุบัติเหตุ หรือสถานการณ์ผิดปกติใดๆ ที่ทำให้ระบบไม่สามารถทำงานได้ตามที่ต้องการ โดยทั่วไปมีจุดประสงค์สองประการคือ เพื่อให้ปลอดภัย (Safe) หรือเพื่อความมั่นคง (Secure) ซึ่งสองอย่างนี้ต่างกัน

ตัวอย่างที่แสดงให้เห็นความแตกต่างของทั้งสองแบบเช่น ในการออกแบบประตูบริเวณศูนย์ข้อมูล (Data Center) ซึ่งใช้ Access Control ในการควบคุมการเข้าออกศูนย์ข้อมูล ในกรณีที่เกิดเหตุฉุกเฉินเช่นเพลิงไหม้ ในบริเวณที่พนักงานนั่งทำงานจะต้องออกแบบให้ Fail-Safe คือหากไฟดับประตูต้องเปิดทันทีเพื่ออพยพคนออก แต่ห้องเครื่องศูนย์ข้อมูลจะต้องออกแบบให้ Fail-Secure คือเมื่อตัดไฟต้องปิดประตูเสมอเพื่อป้องกันคนเข้าถึงเครื่องแม่ข่ายหรืออุปกรณ์เครือข่ายโดยไม่ได้รับอนุญาต

หรือในกรณีอุปกรณ์ Security บนเครือข่าย อุปกรณ์ Firewall จะมีโครงสร้างเป็นแบบ Fail-Secure คือเมื่อมีการขัดข้อง จะแยกเครือข่ายที่เชื่อมกันออกจากกัน ไม่ยอมให้เครือข่ายข้ามถึงกัน แต่ IPS (Intrusion Prevention System) ซึ่งวางขวางระบบเครือข่ายเช่นกันจะทำในทางตรงกันข้าม คือหากขัดข้องจะมีการ Bypass เครือข่ายอัตโนมัติ ซึ่งเป็นแนวทาง Fail-Safe

แล้วในกรณีการออกแบบซอฟต์แวร์ เราจะใช้หลักการ Fail-Safe หรือ Fail-Secure อย่างไร ขอให้หลักการไว้คร่าวๆ ดังนี้

  • หากอยู่ในเงื่อนไขที่ต้องการ Availability มากกว่า Confidentiality หรือ Integrity ให้ออกแบบส่วนนั้นเป็น Fail-Safe เช่นการออกแบบ User Interface ต่างๆ บน Web Application เมื่อเกิด Error 4xx หรือ 5xx ก็ควรจะมี Landing Page ให้คำแนะนำกับผู้ใช้ และมีลิ้งค์ไปยังหน้าแรกที่เป็น Static Page หรือหน้า Login เพื่อป้องกันไม่ให้ผู้ใช้ดำเนินการที่ทำให้ระบบมีปัญหาเพิ่มขึ้นเช่นกดปุ่ม Refresh ของ Web Page เพื่อทำงานซ้ำ
  • หากอยู่ในเงื่อนไขที่ต้องการ Confidentiality หรือ Integrity มากกว่า Availability ให้ออกแบบส่วนนั้นเป็น Fail-Secure เช่นการทำ Financial Transaction หากเกิดข้อผิดพลาดทางใดทางหนึ่งเช่นการโอนเงินจากบัญชีหนึ่งไปยังอีกบัญชีหนึ่งของอีกธนาคาร สามารถตัดบัญชีต้นทางได้แต่ไม่สามารถเอาเข้าบัญชีปลายทางได้ไม่ว่าจะเกิดจากระบบที่ใช้โอน ผู้ให้บริการโอน (Switching) การสื่อสารขัดข้อง หรือกรณีใดก็แล้วแต่ จะต้องทำการย้อนกลับ (Rollback) ทันที

สิ่งหนึ่งที่สำคัญในการออกแบบซอฟต์แวร์ที่มีลักษณะ Fail-Safe/Fail-Secure ให้ได้ดีคือการจำลองกรณีผิดพลาดให้ได้มากที่สุดว่าเกิดจากอะไรได้บ้าง แล้วหาเส้นแบ่งในการตรวจสอบข้อผิดพลาดนั้นๆ (Threshold) เพื่อตัดสินใจว่าจะเข้าสู่กระบวนการจัดการความล้มเหลวของระบบ

จำไว้เสมอว่าซอฟต์แวร์ที่ดี ต้องออกแบบให้มีการจัดการข้อผิดพลาดเมื่อระบบส่วนใดส่วนหนึ่งทำงานล่มไม่เป็นไปตามความต้องการ

ตอนที่เกี่ยวข้อง


29 มกราคม 2559

Secure Software Design 101: Need to Know

การออกแบบซอฟต์แวร์ให้มั่นคงปลอดภัยในในหัวข้อนี้ เป็นเรื่องของการเข้าถึงข้อมูล และเกี่ยวข้องกับเรื่องการรักษาความลับ (Confidentiality) โดยตรง หลักการนี้กล่าวว่า ถึงแม้ว่าใครก็ตามได้รับอนุญาตให้เข้าถึงข้อมูลไม่ว่าจะเป็นชั้นความลับระดับใดก็ตาม ก็ไม่สามารถเห็นข้อมูลนั้นได้จนกว่าจะมีความจำเป็นที่ต้องรู้ข้อมูล (Need to Know) เพื่อที่จะใช้ในการปฏิบัติงาน และไม่จำเป็นต้องเห็นข้อมูลทุกอย่าง เว้นแต่ข้อมูลที่เกี่ยวข้อง

ตัวอย่างเช่นในระบบตรวจสอบการให้สินเชื่อ เมื่อทำการยื่นขอกู้แล้วนั้น ข้อมูลของการยื่นกู้มีหลายอย่าง เช่นข้อมูลผู้กู้ ได้แก่ชื่อ ที่อยู่ทั้งที่บ้านและที่ทำงาน หมายเลขโทรศัพท์ เงินเดือน วงเงินขอกู้ หรือแม้แต่ข้อมูลของผู้ค้ำประกันได้แก่ชื่อ ที่อยู่ เหล่านี้เป็นต้น พนักงานป้อนข้อมูลได้รับอนุญาตให้เข้าถึงข้อมูลเหล่านี้ซึ่งมีชั้นความลับเป็นปกปิด (Restricted) เหมือนกันทุกคนแต่ว่าแต่ละคนจะเห็นข้อมูลเฉพาะรายที่ตนเองได้รับมอบหมายให้ป้อนเท่านั้น ไม่มีสิทธิที่จะอ่านข้อมูลของการยื่นกู้ของรายอื่นที่ไม่ได้ป้อนเข้าไป

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

Need to Know มักจะถูกใช้สับสนกับ Least Privilege เนื่องจากเป็นเรื่องการควบคุมสิทธิ์เช่นเดียวกัน โดยข้อแตกต่างจะสรุปได้ดังนี้
ข้อเปรียบเทียบ Need to Know Least Privilege
การเข้าถึง อ่านเท่านั้น อ่าน เขียน สั่งให้ทำงาน เป็นต้น
Object ข้อมูลเท่านั้น ข้อมูล แฟ้ม บริการ กระบวนการ เป็นต้น
Security Foundation Confidentiality Confidentiality, Integrity
การควบคุมการเข้าถึงข้อมูล ระดับ Record & Field ระดับSchema (อาจถึงระดับ Field)
สิทธิ์ ตามที่ได้รับมอบหมาย(Assignment) ตามบทบาท(Role)

จำไว้เสมอว่า Subject ควรได้รับข้อมูลเฉพาะที่จำเป็นต้องรู้เพื่อทำงานตามหน้าที่ที่ได้รับมอบหมายเท่านั้น

ตอนที่เกี่ยวข้อง


27 มกราคม 2559

Secure Software Design 101: Least Privilege

ในการออกแบบทางด้าน Security สิ่งหนึ่งที่มักจะพูดถึงก็คือเรื่องการให้สิทธิ (Authorization) เพื่อทำงานใดๆ ไม่ว่าจะเป็นระดับผู้ใช้ (User) หรือกระบวนการ (Process) ซึ่งเราเรียกรวมกันว่าประธานหรือผู้กระทำ (ขอใช้ทับศัพท์ว่า Subject or Actor) กระทำการใดๆ ต่อข้อมูล บริการ (Service) หรือแม้แต่กระบวนการ (Process) ด้วยกันเอง ซึ่งเรียกรวมๆ กันว่ากรรม (ขอใช้ทับศัพท์ว่า Object) ซึ่งสามารถเขียนเป็นตัวอย่างการรวมกันของ ประธาน กริยา กรรม ได้เช่น
ประธาน (Subject)กริยา (Access)กรรม (Object)
ผู้ใช้ (User)
โปรแกรม (Program)
กระบวนการ(Process)
อ่าน (Read)
เขียน (Write)
สั่งให้ทำงาน(Execute)
แฟ้มข้อมูล (File)
ฐานข้อมูล(Database)
บริการ (Service)
กระบวนการ(Process)
ทรัพยากร(Resource)

การออกแบบการให้สิทธินั้นมีแนวคิดเพื่อความมั่นคงปลอดภัยก็คือการให้สิทธิ Subject ดำเนินการต่อ Object น้อยที่สุดเท่าที่จะทำงานได้สำเร็จตามวัตถุประสงค์ หรือที่เรียกว่า Least Privilege เช่น Web Application ซึ่งทำงานกับ Database เพียงแค่ insert, select, update, delete ก็ควรจะสร้าง Database User ให้กับ Web Application นั้นให้มีสิทธิ์เท่าที่ทำงานดังกล่าวได้ ไม่ใช่ปล่อยให้ใช้ User ที่มีสิทธิ์สูงเช่น SA, root, SYS หรือ Schema Owner หรือ User ที่สามารถใช้คำสั่งจัดการ Schema ของข้อมูล (DDL: Data Definition Language) เช่น create, alter, drop เป็นต้น

สิทธิดังกล่าวข้างต้นเป็นสิทธิในเชิงวิธีการเข้าถึง แต่ยังมีในเชิงปริมาณที่ต้องคำนึงถึงคือจำนวนและชนิดของ Object ที่เข้าใช้งาน หลักการ Lease Privilege ก็ครอบคลุมในมิตินี้ด้วย กล่าวคือหาก Subject ไม่มีความจำเป็นที่ต้องทำงานกับ Object ใด ก็ควรห้ามการเข้าถึง Object นั้นๆ ด้วย

การให้สิทธิ์แก่ Subject มากเท่าไรก็เป็นการเพิ่มพื้นที่ในการโจมตี (Attack Surface) ต่อ Object มากเท่านั้นและเมื่อ Subject โดนยึดได้ (Compromised) Object ก็มีโอกาสถูกกระทำตามสิทธิที่ให้แก่ Subject ไว้

จำไว้เสมอว่า ให้ Subject มีสิทธิยิ่งน้อยเท่าไรความเสี่ยงในการที่ Subject จะถูกสวมรอยเพื่อใช้ทำงานผิดวัตถุประสงค์หรือทำงานผิดพลาดโดยไม่ตั้งใจ (User Error) จะมีน้อยเท่านั้น

ตอนที่เกี่ยวข้อง


29 พฤศจิกายน 2558

ว่าด้วยเรื่อง Unicode

จากเมื่อวานต้องเขียนโปรแกรมดึงข้อมูลจาก mdb (Microsoft Jet ที่เราชอบเรียก MS Access File) ที่เขียนไว้ใช้กับ VB6 ตั้งแต่สมัย Windows 98 แปลงมาเป็น SQLite3 เพื่อให้ใช้ได้ทุก Platform ด้วยโปรแกรมที่เขียนด้วย Python จากข้อมูลเดิม Text เป็น ASCII Windows 874 ต้องมาใช้ Unicode ที่ SQLite รองรับ

เพราะต้องการจะเขียนให้จบเร็วจึงตัดสินใจใช้วิธีแปลงข้อมูลใน Table ของ MS Access เป็น SQL command (INSERT INTO) ลง Text File เพื่อเรียกใช้โดย sqlite3.exe command line จากโครงการ SQLite อีกทีหนึ่ง

ปัญหาคือแม้บอกว่าเป็น Unicode แต่ Unicode ก็ไม่ได้มีแบบเดียว มี UTF-8 และ UTF-16 แล้ว UTF-16 ยังมีแบบ Little Endian และ Big Endian อีก อย่างไรก็ตามโปรแกรมที่ทำการแปลงข้อมูลต้องทำบน Windows เพื่อให้คนอื่นใช้ บน Windows x86 เก็บ Character บน Memory เป็น 16 bit Little Endian

ทดลองเขียนไฟล์เป็น UTF16LE ก็ปรากฏว่า sqlite3.exe อ่านได้ แต่เก็บข้อมูลภาษาไทยผิด ทั้งที่จากการตรวจสอบไฟล์ SQL statement เปิดด้วย Text Editor ก็อ่านถูก เลยตัดสินใจเปลี่ยนเป็น UTF-8 ซึ่งต้องเปลี่ยน Library ด้วย เขียนแล้วก็เปิดด้วย Text Editor แสดงเป็น UTF-8 ได้ แต่ sqlite3.exe อ่านไม่ผ่าน เหมือนว่าไม่รู้จัก 3 byte แรก อะไรหว่า

ก็พบว่า UTF-8 Text File ก็ยังมี 2 แบบอีกคือ แบบมี BOM (Byte Order Mark) กับไม่มี ซึ่ง sqlite3.exe ต้องไม่มี เลยต้องตัด 3 byte แรกออกและเขียนเป็น Binary ลง Text File (ห้ามงง) ถึงจะผ่านฉลุย

อยากรู้ว่าทำไมชีวิตกับ Unicode ถึงอยู่ยากจัง