ความปลอดภัยในการสร้าง API ที่ควรรู้ ซึ่งเป็นเรื่องที่ 2 ใน series ชุด OWASP API 2019 ว่าด้วยเรื่อง Broken User Authentication นะครับ สำหรับผู้อ่านที่ยังไม่ทราบว่า OWASP คือใคร สามารถค้นหาได้จาก google เลยครับมีเพียบ แต่ถ้าอยากอ่านจากต้นฉบับไปที่นี่เลย Projects | OWASP มีรายละเอียดเยอะมาก

เริ่มกันเลยดีกว่า

ตามนิยามต้นฉบับ

API2:2019 Broken User Authentication

Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities temporarily or permanently. Compromising a system’s ability to identify the client/user, compromises API security overall.

แปลกันด้วย google translate

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

อ่านดูก็พอจะเข้าใจนะ แต่มาตีความโดยความเข้าใจกันดีกว่า

เรื่องการทำ Authentication ที่มักจะเอาไป implement กับแบบผิดๆ หรือไม่ถูกวิธี จะทำให้ attacker หรือผู้ไม่หวังดี/ผู้บุกรุก สามารถยึด authentication token มาใช้ประโยชน์จากช่องโหว่เสมือนกับ ผู้ใช้งานเข้ามาเอง โดยระบบที่ถูกโจมตีในรูปแบบนี้ จะทำให้ความปลอดภัยของ API ในภาพรวมของระบบลดลงในทันที

ในภาพรวมนิยามจะคล้าย ๆ กับ A2:2017-Broken Authentication ใน Top 10 Web Application Security Risks ซึ่งสามารถอ่านเพิ่มเติมได้ที่ Broken Authentication. | by Oraphanthong T. | blog blog

แบบไหนละที่เรียกว่าเสี่ยง

• ระบบไม่มีการดักให้ไม่สามารถสร้าง/แจ้งเตือน พวก user หรือ password ยอดนิยม หรือ default user/password เพราะ attacker อาจจะใช้ user / password เหล่านี้มาลองเข้าระบบ
• api ยอมให้ attacker ทำ brute force บน user ซ้ำๆ โดยไม่มี captcha
• ยอมให้มีการสร้าง weak password ซึ่งตรงข้ามกับ strong password
• มีการส่งข้อมูล sensitive เช่น auth tokens และ password ใน url
• ไม่มีการตรวจสอบ token
• ยอมให้มีการใช้งาน weak signed JWT token โดยอาจจะรวมไปถึง expire date
• ใช้ plain text, non-encrypt, weakly hashed password
• ใช้ weak encryption keys

แนวทางป้องกัน

• ต้องเข้าใจเกี่ยวกับเรื่องการทำ authentication เพื่อจะได้รู้ว่าจะจัดการอย่างไร
• Don’t reinvent the wheel in authentication, token generation, password storage. Use the standard. (ข้อนี้ขอยกภาษาอังกฤษมาทั้งหมด เนื่องจากมีน้องใน office คนนึงชอบพูดข้อความประมาณนี้)
• ให้ศึกษา OWASP Authentication Cheatsheet
• ถ้าเป็นไปได้ให้ใช้ multi-factor authentication (ใช้หลายๆ เครื่องมือในการยืนยันตัวตน)
• หาทาง implement anti brute force อ่านรายละเอียดเพิ่มเติม

ส่งท้าย

OWASP API 2019 ถือเป็นโครงการในระดับ Lab Project ซึ่งในนิยามคือ โครงการที่ OWASP ได้ตรวจสอบแล้วใช้งานได้แต่ยังไม่ถึงขั้น Flagship เหมือน OWASP Top Ten Web Application Security Risks ในความหมายคือ เป็น Project ที่นิ่งระดับหนึ่งแต่ยังมีโอกาสให้มีการพัฒนาในแง่ของเอกสาร หรือตัวอย่างมากขึ้นในอนาคต เพื่อให้ได้รับคัดเลือกเป็น Flagship

ซึ่งทาง OWASP ได้จัดระดับของโครงการไว้ 3 แบบคือ Flagship Projects, Lab Projects และ Incubator Projects

หวังว่าอนาคตเราจะได้มาศึกษา Project อื่นๆ ของ OWASP กันอีกนะครับ ไม่ว่าจะเป็น OWASP Mobile Top 10 OWASP Docker Top 10 กดติดตามกันไว้

reference:

OWASP API Security — Top 10 | OWASP

https://github.com/OWASP/API-Security/raw/master/2019/en/dist/owasp-api-security-top-10.pdf

รวม 25 อันดับ Password ยอดแย่ที่สุดประจำปี 2019 เผยรหัส 123456 ครองแชมป์ 7 ปีซ้อน | DroidSans

OWASP API 2019 : API-2 Broken User Authentication was originally published in blog blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

แล้วเราก็มาถึงหัวข้อ OWASP Top10–2017 A3 Sensitive Data Exposure

คืออะไร:

เรื่อง Sensitive Data Exposure เป็นหัวข้อมาตั้งแต่ OWASP Top10 2013 2013-A6: Sensitive Data Exposure แต่ถ้าจะให้ลึกไปกว่านั้น จริงๆ มันเกิดมาตั้งแต่ OWASP Top10 2010 เกิดจากการรวมกันของ 2010-A7 — Insecure Cryptographic Storage & 2010-A9 — Insufficient Transport Layer Protection แสดงว่ามันต้องมีความสำคัญจริงๆ

ว่าแต่มันคือะไรเหรอตามคำนิยามที่เค้าว่าไว้

Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.

แปลได้ความว่า Web หรือ API ที่ไม่ได้มีการป้องกัน หรือป้องกันได้ไม่ดีพอ เกี่ยวกับข้อมูลที่มีความสำคัญ เช่นข้อมูลทางด้านการเงิน สุขภาพ รวมถึง PII(ศัพท์ใหม่ ไม่เคยได้ยิน 55 คร่าวๆ คือข้อมูลที่ใช้ระบุตัวบุคคลได้ เดี๋ยวไว้ด้านล่างค่อยมาดูว่ามันคืออะไร ) ซึ่งอาจส่งผลให้ผู้ไม่หวังดี(Attacker) อาจจะขโมยหรือแก้ไขข้อมูล เพื่อกระทำการบางอย่างที่ไม่ดีต่อไป

แล้วอะไรบ้างที่ถือว่าเสี่ยง คงต้องมานิยามใน Application ของเราก่อนว่าอะไรบ้างที่ถือว่าเป็น Sensitive Data เช่น password หมายเลขบัตรเครดิต จริงๆ แล้วพวกหมายเลขบัตรประชาชน นี่ก็ถือเป็น sensitive data ด้วยนะ เพราะในหลายๆ ระบบอาจจะมีการใช้หมายเลขบัตรในการยืนยันตัวตน โดยอาจจะรวมถึงข้อมูลอื่นๆ ที่อยู่ในนิยามทางด้านกฎหมาย เช่น GDPR หรือกฎอื่นๆ แล้วแต่เรื่อง(หมายความว่าอาจจะต้องมานิยามตามแต่บริบทของการใช้งานในโปรแกรมนั้น)

ในการส่งข้อมูล — ระหว่างที่เก็บกับปลายทาง ข้อมูลเหล่านั้นมีการเข้ารหัสไว้หรือไม่ ไม่ควรส่งเป็นข้อความที่มองแล้วดูรู้เลย protocol ที่ใช้ เหมาะสมมั๊ย https, sftp, ..
การเก็บข้อมูล — ก่อนเก็บมีการเข้ารหัสหรือไม่
algorithm — เราใช้ algorithm ที่เข้ารหัสแบบที่มีความ strong พอหรือไม่ ** อาจจะต้องตั้งเป็นรอบของการ review เอาไว้ เพราะพวก algorithm ที่เคยใช้ได้ หรือยอมรับในอดีต ไม่ได้หมายความว่าปัจจุบันจะใช้ได้เสมอไป ด้วยเทคโนโลยีหรือ hardware ที่เปลี่ยนไป ทำให้การถอดรหัสทำได้ง่ายขึ้น
รวมถึง user agent ต่างๆที่ใช้ มีการเช็ค server certificate มั๊ยว่ายัง valid อยู่

แนวทางการป้องกัน
1 classify
2 กำหนด control ตามการแยกกลุ่มประเภท
3 ถ้าไม่จำเป็นไม่ควรเก็บ sensitive data หรือใช้เสร็จให้รีบเคลียร์
4 อย่าลืม encrypt data
5 up-to-date strong standard algorithm รวมถึง protocol และใช้ key management ที่เหมาะสม
6 การส่งข้อมูลควรส่งผ่าน protocol ที่ secure เช่น TLS => มีหลาย version และมีประวัติศาสตร์ รวมถึงการใช้ HSTS
7 disable cache กรณีที่ response มีข้อมูลพวก sensitive
8 password ควรใช้ strong adaptive และ salted hashing function with a work factor เช่น Argon2, scrypt, bcrypt หรือ PBKDF2

ทุกวันนี้คุณเก็บ password แบบ one-way ด้วย hashing function แล้วหรือยังงงงง

Part หน้าเรามาลงลึกทางด้าน Technical กันบ้าง

ก่อนจากกัน เรามาย้ำกันอีกครั้งว่า เรื่อง Security เป็นเรื่องของทุกคน เราจะต้องให้ความสนใจกับเรื่องนี้ให้มากๆ โดยเฉพาะ Developer ที่เป็นต้นทางของการสร้าง software โดยหวังว่า series ชุด OWASP Top10 2017 จะเป็นจุดเริ่มต้นของการตระหนักด้าน software security ให้กับผู้อ่าน

ทิ้งท้าย หาข้อมูลเพิ่มเติมได้ที่ไหน ที่นี่เลย https://www.owasp.org ข้อมูลหลักที่รวบรวมข้อมูลด้าน security ไว้ มีคลังมากมายสามารถเข้าไปค้นคว้าได้

PII => Personally Identifiable Information จากความหมายใน wiki คือ ข้อมูลที่สามารถใช้ระบุตัว ติดต่อหรือค้นหาบุคคลหนึ่งบุคคลใดโดยเฉพาะ หรือเป็นข้อมูลที่ใช้ร่วมกับข้อมูลอื่นเพื่อระบุตัวบุคคลหนึ่งบุคคลใด สนใจสามารถค้นคว้าต่อได้ที่ https://th.wikipedia.org/wiki/ข้อมูลที่ระบุตัวบุคคลได้ ในนั้นจะบอกถึงว่าข้อมูลอะไรบ้างที่ถือว่าเป็น PII แต่อาจจะเป็นแค่ตัวอย่างของอเมริกา แต่ก็คือว่าใช้เป็นหลักได้

ref:

• Category:OWASP Top Ten Project - OWASP
• Top 10 2013-Release Notes - OWASP
• เข้ารหัส Password ด้วย Hash function กับ Salt values
• Hash: ไม่รู้ว่ามันคืออะไรแต่มันใช่

A3-Sensitive Data Exposure was originally published in blog blog on Medium, where people are continuing the conversation by highlighting and responding to this story.