Awesome Application Security Checklist

การตรวจสอบความปลอดภัยที่ยอดเยี่ยม

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

ระบบตรวจสอบความถูกต้อง (การลงทะเบียน/ลงชื่อเข้าใช้/2 ปัจจัย/รีเซ็ตรหัสผ่าน)

• ใช้ HTTPS ทุกที่
• เก็บรหัสผ่านแฮชโดยใช้ Bcrypt (ไม่จำเป็นต้องเกลือ - Bcrypt ทำเพื่อคุณ)
• ทำลายตัวระบุเซสชันหลังจาก logout
• ทำลายเซสชันที่ใช้งานอยู่ทั้งหมดบนรหัสผ่านรีเซ็ต (หรือเสนอ)
• ต้องมีพารามิเตอร์ state ใน OAuth2
• ไม่มีการเปลี่ยนเส้นทางแบบเปิดหลังจากเข้าสู่ระบบที่ประสบความสำเร็จหรือในการเปลี่ยนเส้นทางขั้นกลางอื่น ๆ
• เมื่อแยกวิเคราะห์การลงทะเบียน/เข้าสู่ระบบอินพุต sanitize สำหรับ JavaScript: //, data: //, อักขระ CRLF
• ตั้งค่าคุกกี้ที่ปลอดภัย httponly
• ในการตรวจสอบมือถือที่ใช้ OTP บนมือถืออย่าส่ง OTP กลับมาในการตอบกลับเมื่อ generate OTP หรือ Resend OTP API ใหม่อีกครั้ง
• จำกัด ความพยายามใน Login Verify OTP Resend OTP และ generate OTP APIs สำหรับผู้ใช้เฉพาะ มีชุด backoff แบบเอ็กซ์โปเนนเชียลหรือ/และบางอย่างเช่นความท้าทายตาม CAPTCHA
• ตรวจสอบการสุ่มของโทเค็นรหัสผ่านรีเซ็ตในลิงค์อีเมลหรือ SMS
• ตั้งค่าการหมดอายุของโทเค็นรหัสผ่านรีเซ็ตในช่วงเวลาที่เหมาะสม
• หมดอายุโทเค็นรีเซ็ตหลังจากใช้งานสำเร็จ

ข้อมูลผู้ใช้และการอนุญาต

• การเข้าถึงทรัพยากรใด ๆ เช่น my cart my history ควรตรวจสอบความเป็นเจ้าของของผู้ใช้ที่เข้าสู่ระบบของทรัพยากรโดยใช้รหัสเซสชัน
• ควรหลีกเลี่ยงรหัสทรัพยากรที่ทำซ้ำได้ตามลำดับ ใช้ /me/orders แทน /user/37153/orders สิ่งนี้ทำหน้าที่เป็นการตรวจสอบสติในกรณีที่คุณลืมตรวจสอบโทเค็นการอนุญาต
• คุณลักษณะ Edit email/phone number ควรมาพร้อมกับอีเมลยืนยันไปยังเจ้าของบัญชี
• คุณลักษณะการอัปโหลดใด ๆ ควรฆ่าเชื้อชื่อไฟล์ที่ผู้ใช้ให้ไว้ นอกจากนี้ด้วยเหตุผลโดยทั่วไปนอกเหนือจากความปลอดภัยให้อัปโหลดไปยังบางอย่างเช่น S3 (และโพสต์กระบวนการโดยใช้ Lambda) และไม่ใช่เซิร์ฟเวอร์ของคุณเองที่สามารถเรียกใช้รหัสได้
• คุณสมบัติ Profile photo upload ควรฆ่าเชื้อแท็ก EXIF ​​ทั้งหมดหากไม่จำเป็น
• สำหรับรหัสผู้ใช้และรหัสอื่น ๆ ให้ใช้ UUID ที่สอดคล้องกับ RFC แทนจำนวนเต็ม คุณสามารถค้นหาการใช้งานสำหรับภาษาของคุณใน GitHub
• JWT ยอดเยี่ยมมาก ใช้หากจำเป็นสำหรับแอป/APIs หน้าเดียวของคุณ

ฐานข้อมูล

• ใช้การเข้ารหัสสำหรับข้อมูลที่ระบุผู้ใช้และข้อมูลที่ละเอียดอ่อนเช่นโทเค็นการเข้าถึงที่อยู่อีเมลหรือรายละเอียดการเรียกเก็บเงิน
• หากฐานข้อมูลของคุณรองรับการเข้ารหัสต้นทุนต่ำที่เหลือ (เช่น AWS Aurora) ให้เปิดใช้งานเพื่อรักษาความปลอดภัยข้อมูลบนดิสก์ ตรวจสอบให้แน่ใจว่าการสำรองข้อมูลทั้งหมดถูกจัดเก็บไว้เช่นกัน
• ใช้สิทธิ์ขั้นต่ำสำหรับบัญชีผู้ใช้ฐานข้อมูลการเข้าถึงฐานข้อมูล อย่าใช้บัญชีรูทฐานข้อมูล
• จัดเก็บและแจกจ่ายความลับโดยใช้ร้านค้าคีย์ที่ออกแบบมาเพื่อวัตถุประสงค์ ไม่ยากรหัสในแอปพลิเคชันของคุณ
• ป้องกันการฉีด SQL อย่างเต็มที่โดยใช้งบ SQL ที่เตรียมไว้เท่านั้น ตัวอย่างเช่น: หากใช้ NPM อย่าใช้ NPM-MYSQL ให้ใช้ NPM-MYSQL2 ซึ่งรองรับคำสั่งที่เตรียมไว้

แอป Android / iOS

• salt จากเกตเวย์การชำระเงินไม่ควรถูกเก็บไว้
• โทเค็น secret / auth token จาก SDK ของบุคคลที่ 3 ไม่ควรถูกเข้ารหัส
• การโทร API ที่ตั้งใจจะทำ server to server ไม่ควรทำจากแอพ
• ใน Android ควรประเมินสิทธิ์ทั้งหมดที่ได้รับการประเมินอย่างรอบคอบ
• บน iOS ให้เก็บข้อมูลที่ละเอียดอ่อน (โทเค็นการรับรองความถูกต้องปุ่ม API ฯลฯ ) ในพวงกุญแจระบบ อย่า เก็บข้อมูลประเภทนี้ไว้ในค่าเริ่มต้นของผู้ใช้
• ขอแนะนำให้ใช้ใบรับรอง

ส่วนหัวความปลอดภัยและการกำหนดค่า

• Add ส่วนหัว CSP เพื่อลด XSS และการโจมตีการฉีดข้อมูล นี่เป็นสิ่งสำคัญ
• Add ส่วนหัว CSRF เพื่อป้องกันการปลอมแปลงคำขอข้ามไซต์ เพิ่มแอตทริบิวต์ samesite ในคุกกี้
• Add ส่วนหัว HSTS เพื่อป้องกันการโจมตี SSL
• Add โดเมนของคุณในรายการ HSTS preload
• Add ตัวเลือก X-Frame เพื่อป้องกันการคลิก Jacking
• Add ส่วนหัวการป้องกัน X-XSS เพื่อลดการโจมตี XSS
• อัปเดต DNS Records เพื่อเพิ่มบันทึก SPF เพื่อลดการโจมตีสแปมและการโจมตีแบบฟิชชิง
• เพิ่มการตรวจสอบความสมบูรณ์ของ Subresource หากโหลดไลบรารี JavaScript ของคุณจาก CDN ของบุคคลที่สาม เพื่อความปลอดภัยเพิ่มเติมให้เพิ่มความต้องการ CSP-directive เพื่อให้คุณไม่โหลดทรัพยากรที่ไม่มี SRI SAT
• ใช้โทเค็น CSRF แบบสุ่มและเปิดเผย APIs ทางธุรกิจตามคำขอโพสต์ HTTP อย่าเปิดเผยโทเค็น CSRF ผ่าน HTTP ตัวอย่างเช่นในขั้นตอนการอัพเกรดการร้องขอเริ่มต้น
• อย่าใช้ข้อมูลที่สำคัญหรือโทเค็นในพารามิเตอร์ GET Request การเปิดรับบันทึกเซิร์ฟเวอร์หรือการประมวลผลของเครื่อง/สแต็กจะเปิดเผยข้อมูลผู้ใช้ในทางกลับกัน

การฆ่าเชื้อ

• Sanitize อินพุตผู้ใช้ทั้งหมดหรือพารามิเตอร์อินพุตใด ๆ ที่เปิดเผยกับผู้ใช้เพื่อป้องกัน XSS
• ใช้แบบสอบถามพารามิเตอร์เสมอเพื่อป้องกันการฉีด SQL
• ใส่อินพุตผู้ใช้ในการฆ่าเชื้อหากใช้โดยตรงสำหรับฟังก์ชันการทำงานเช่นการนำเข้า CSV
• Sanitize ผู้ใช้อินพุตสำหรับกรณีพิเศษเช่น robots.txt เป็นชื่อโปรไฟล์ในกรณีที่คุณใช้รูปแบบ URL เช่น coolcorp.io/username
• อย่าใช้รหัสมือหรือสร้าง JSON โดยการเชื่อมต่อสตริงไม่ว่าวัตถุจะเล็กแค่ไหน ใช้ไลบรารีหรือเฟรมเวิร์กที่กำหนดภาษาของคุณ
• ฆ่าเชื้ออินพุตที่ใช้ URL บางประเภทเพื่อป้องกัน SSRF
• ฆ่าเชื้อโรคก่อนที่จะแสดงให้ผู้ใช้

การปฏิเสธการป้องกันการบริการ

• ตรวจสอบให้แน่ใจว่า DOS โจมตี API ของคุณจะไม่ทำลายเว็บไซต์ของคุณ อย่างน้อยที่สุดมีตัว จำกัด อัตราบนเส้นทาง API ที่ช้ากว่าของคุณเช่นการเข้าสู่ระบบและการสร้างโทเค็น พิจารณา CAPTCHA ใน APIs ส่วนหน้าเพื่อปกป้องบริการแบ็คเอนด์กับ DOS
• บังคับใช้ขีด จำกัด ด้านสติเกี่ยวกับขนาดและโครงสร้างของผู้ใช้ที่ส่งข้อมูลและคำขอ
• ใช้การลดการปฏิเสธการบริการแบบกระจาย (DDOS) ผ่านบริการพร็อกซีแคชทั่วโลกเช่น CloudFlare สิ่งนี้สามารถเปิดใช้งานได้หากคุณประสบการโจมตี DDOS และทำหน้าที่เป็นการค้นหา DNS ของคุณ

การปฏิบัติการ

• หากคุณมีขนาดเล็กและไม่มีประสบการณ์ให้ประเมินโดยใช้ AWS ElasticBeanstalk หรือ PAAs เพื่อเรียกใช้รหัสของคุณ
• ใช้สคริปต์การจัดเตรียมที่เหมาะสมเพื่อสร้าง VMS ในคลาวด์
• ตรวจสอบเครื่องจักรที่มี open ports สาธารณะที่ไม่ต้องการ
• ตรวจสอบหมายเลข/รหัสผ่านเริ่มต้นสำหรับ databases โดยเฉพาะ MongoDB & Redis
• ใช้ SSH เพื่อเข้าถึงเครื่องของคุณ อย่าตั้งค่ารหัสผ่านใช้การรับรองความถูกต้องตามคีย์ SSH แทน
• ติดตั้งการอัปเดตที่ทันเวลาเพื่อดำเนินการตามช่องโหว่ของศูนย์วันเช่น Heartbleed, Shellshock
• แก้ไขการกำหนดค่าเซิร์ฟเวอร์เพื่อใช้ TLS 1.2 สำหรับ HTTPS และปิดใช้งานรูปแบบอื่น ๆ ทั้งหมด (การแลกเปลี่ยนเป็นสิ่งที่ดี)
• อย่าเปิดโหมดการดีบัก ในบางเฟรมเวิร์กโหมดการดีบักสามารถให้การเข้าถึง REPL หรือเชลล์เต็มรูปแบบหรือเปิดเผยข้อมูลที่สำคัญในข้อความแสดงข้อผิดพลาด stacktraces
• เตรียมพร้อมสำหรับนักแสดงและ DDOS ที่ไม่ดี - ใช้บริการโฮสติ้งที่มีการบรรเทา DDOS
• ตั้งค่าการตรวจสอบสำหรับระบบของคุณและบันทึกสิ่งของ (ใช้ Relic ใหม่หรืออะไรทำนองนั้น)
• หากพัฒนาสำหรับลูกค้าองค์กรให้ปฏิบัติตามข้อกำหนดการปฏิบัติตามข้อกำหนด หาก AWS S3 ให้พิจารณาใช้คุณสมบัติเพื่อเข้ารหัสข้อมูล หากใช้ AWS EC2 ให้พิจารณาการใช้คุณสมบัติเพื่อใช้ปริมาตรที่เข้ารหัส (แม้กระทั่งปริมาณการบูตสามารถเข้ารหัสได้ในขณะนี้)

การกำหนดค่าคลาวด์

• ตรวจสอบให้แน่ใจว่าบริการทั้งหมดเปิดพอร์ตขั้นต่ำ ในขณะที่การรักษาความปลอดภัยผ่านความสับสนนั้นไม่มีการป้องกันการใช้พอร์ตที่ไม่ได้มาตรฐานจะทำให้ผู้โจมตียากขึ้นเล็กน้อย
• ฐานข้อมูลแบ็กเอนด์โฮสต์และบริการเกี่ยวกับ VPC ส่วนตัวที่ไม่สามารถมองเห็นได้ในเครือข่ายสาธารณะใด ๆ ระวังให้มากเมื่อกำหนดค่ากลุ่มความปลอดภัย AWS และการมอง VPCs ซึ่งสามารถทำให้บริการที่เปิดเผยต่อสาธารณชนโดยไม่ได้ตั้งใจ
• แยกบริการตรรกะใน VPCs แยกต่างหากและ VPC แบบเพียร์เพื่อให้การสื่อสารระหว่างบริการ
• ตรวจสอบให้แน่ใจว่าบริการทั้งหมดยอมรับข้อมูลจากที่อยู่ IP น้อยที่สุด
• จำกัด การรับส่งข้อมูล IP และพอร์ตขาออกเพื่อลด APTS และ“ Botification”
• ใช้บทบาท AWS IAM เสมอและไม่ใช่ข้อมูลรับรองรูท
• ใช้สิทธิ์การเข้าถึงขั้นต่ำสำหรับ OPS และพนักงานนักพัฒนาทั้งหมด
• หมุนรหัสผ่านเป็นประจำและปุ่มเข้าถึงตามกำหนดเวลา

CI & CD ตรวจสอบการออกแบบและการใช้งานของคุณด้วยการทดสอบหน่วย/การรวมการทดสอบ ใช้กระบวนการตรวจสอบรหัสและไม่สนใจการอนุมัติตนเอง ตรวจสอบให้แน่ใจว่าส่วนประกอบทั้งหมดของบริการของคุณถูกสแกนโดยซอฟต์แวร์ AV แบบคงที่ก่อนที่จะผลักดันการผลิตรวมถึงไลบรารีผู้ขายและการอ้างอิงอื่น ๆ ออกแบบโซลูชันการย้อนกลับสำหรับการปรับใช้

ประชากร

• ตั้งค่าอีเมล (เช่น [email protected]) และหน้าสำหรับนักวิจัยด้านความปลอดภัยเพื่อรายงานช่องโหว่
• ขึ้นอยู่กับสิ่งที่คุณกำลังทำ จำกัด การเข้าถึงฐานข้อมูลผู้ใช้ของคุณ
• สุภาพต่อนักข่าวบั๊ก
• ให้การตรวจสอบรหัสของคุณเสร็จสิ้นโดยเพื่อนนักพัฒนาจากมุมมองการเข้ารหัสที่ปลอดภัย (ตามากขึ้น)
• ในกรณีที่มีการแฮ็กหรือการละเมิดข้อมูลให้ตรวจสอบบันทึกก่อนหน้าสำหรับการเข้าถึงข้อมูลขอให้ผู้คนเปลี่ยนรหัสผ่าน คุณอาจต้องการการตรวจสอบโดยหน่วยงานภายนอกขึ้นอยู่กับตำแหน่งที่คุณอยู่

โครงสร้างพื้นฐาน

• ตรวจสอบให้แน่ใจว่าคุณสามารถอัพเกรดได้โดยไม่หยุดทำงาน ตรวจสอบให้แน่ใจว่าคุณสามารถอัปเดตซอฟต์แวร์ได้อย่างรวดเร็วในลักษณะอัตโนมัติอย่างสมบูรณ์
• สร้างโครงสร้างพื้นฐานทั้งหมดโดยใช้เครื่องมือเช่น Terraform และไม่ผ่านคอนโซลคลาวด์ โครงสร้างพื้นฐานควรถูกกำหนดให้เป็น“ รหัส” และสามารถสร้างขึ้นใหม่ได้ด้วยการกดปุ่มเพียงปุ่มเดียว มีความอดทนเป็นศูนย์สำหรับทรัพยากรใด ๆ ที่สร้างขึ้นในคลาวด์ด้วยมือ - Terraform สามารถตรวจสอบการกำหนดค่าของคุณได้
• ใช้การบันทึกแบบรวมศูนย์สำหรับบริการทั้งหมด คุณไม่ควรต้องใช้ SSH ในการเข้าถึงหรือดึงบันทึก
• อย่า SSH เป็นบริการยกเว้นการวินิจฉัยครั้งเดียว การใช้ SSH เป็นประจำโดยทั่วไปหมายความว่าคุณไม่ได้เป็นงานที่สำคัญโดยอัตโนมัติ
• อย่าให้พอร์ต 22 เปิดในกลุ่มบริการ AWS ใด ๆ อย่างถาวร พิจารณาอนุญาตให้ IPS ที่ได้รับอนุญาตเพียง SSH ในกล่อง
• สร้างโฮสต์ที่ไม่เปลี่ยนรูปแทนเซิร์ฟเวอร์ที่มีอายุยืนยาวที่คุณแก้ไขและอัพเกรด (ดูโครงสร้างพื้นฐานที่ไม่เปลี่ยนรูปสามารถรักษาความปลอดภัยได้มากขึ้น)
• ใช้ระบบตรวจจับการบุกรุกเช่น Sensedeep หรือ Service เพื่อลด APTS