การทดสอบความปลอดภัย - คู่มือฉบับย่อ

การทดสอบความปลอดภัยเป็นสิ่งสำคัญมากในการป้องกันระบบจากกิจกรรมที่เป็นอันตรายบนเว็บ

การทดสอบความปลอดภัยคืออะไร?

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

การทดสอบความปลอดภัยใช้มาตรการหกประการต่อไปนี้เพื่อจัดเตรียมสภาพแวดล้อมที่ปลอดภัย -

  • Confidentiality - ป้องกันการเปิดเผยข้อมูลแก่ผู้รับโดยไม่ได้ตั้งใจ

  • Integrity - อนุญาตให้ถ่ายโอนข้อมูลที่ต้องการอย่างถูกต้องและถูกต้องจากผู้ส่งไปยังผู้รับที่ต้องการ

  • Authentication - ตรวจสอบและยืนยันตัวตนของผู้ใช้

  • Authorization - ระบุสิทธิ์การเข้าถึงผู้ใช้และทรัพยากร

  • Availability - ช่วยให้มั่นใจได้ถึงความพร้อมของข้อมูลตามความต้องการ

  • Non-repudiation - ช่วยให้มั่นใจได้ว่าไม่มีการปฏิเสธจากผู้ส่งหรือผู้รับว่ามีการส่งหรือรับข้อความ

ตัวอย่าง

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

  • ลงชื่อเข้าใช้เว็บแอปพลิเคชันโดยใช้ข้อมูลรับรองที่ถูกต้อง

  • ออกจากระบบเว็บแอปพลิเคชัน

  • คลิกปุ่ม BACK ของเบราว์เซอร์

  • ตรวจสอบว่าคุณถูกขอให้เข้าสู่ระบบอีกครั้งหรือว่าคุณสามารถกลับไปที่หน้าล็อกอินได้อีกครั้ง

การทดสอบความปลอดภัยถือได้ว่าเป็นการโจมตีที่มีการควบคุมในระบบซึ่งเปิดเผยข้อบกพร่องด้านความปลอดภัยในลักษณะที่เป็นจริง เป้าหมายคือการประเมินสถานะปัจจุบันของระบบไอที เป็นที่รู้จักกันในชื่อpenetration test หรือเป็นที่นิยมมากขึ้นเช่น ethical hacking.

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

การทดสอบการเจาะ - เวิร์กโฟลว์

การทดสอบการเจาะประกอบด้วยสี่ขั้นตอนสำคัญ -

  • การพิมพ์เท้า
  • Scanning
  • Enumeration
  • Exploitation

ขั้นตอนทั้งสี่นี้จะวนซ้ำหลาย ๆ ครั้งซึ่งจะไปพร้อมกับ SDLC ปกติ

ซอฟต์แวร์ที่เป็นอันตราย (มัลแวร์) คือซอฟต์แวร์ใด ๆ ที่ให้ผู้โจมตี / ผู้สร้างมัลแวร์ควบคุมระบบได้บางส่วนและเต็มรูปแบบ

มัลแวร์

รูปแบบต่างๆของมัลแวร์มีดังต่อไปนี้ -

  • Virus- ไวรัสคือโปรแกรมที่สร้างสำเนาของตัวเองและแทรกสำเนาเหล่านี้ลงในโปรแกรมคอมพิวเตอร์อื่นไฟล์ข้อมูลหรือในบูตเซกเตอร์ของฮาร์ดดิสก์ เมื่อจำลองแบบสำเร็จไวรัสจะก่อให้เกิดกิจกรรมที่เป็นอันตรายบนโฮสต์ที่ติดไวรัสเช่นการขโมยพื้นที่ฮาร์ดดิสก์หรือเวลาของ CPU

  • Worm - เวิร์มเป็นมัลแวร์ประเภทหนึ่งที่ทิ้งสำเนาของตัวเองไว้ในหน่วยความจำของคอมพิวเตอร์แต่ละเครื่องในเส้นทางของมัน

  • Trojan - โทรจันเป็นมัลแวร์ประเภทที่ไม่สามารถจำลองตัวเองได้ซึ่งมีรหัสที่เป็นอันตรายซึ่งเมื่อดำเนินการแล้วจะทำให้ข้อมูลสูญหายหรือถูกขโมยหรืออาจเป็นอันตรายต่อระบบได้

  • Adware- แอดแวร์หรือที่เรียกว่าฟรีแวร์หรือพิชแวร์เป็นซอฟต์แวร์คอมพิวเตอร์ฟรีที่มีโฆษณาเกมแถบเครื่องมือเดสก์ท็อปและยูทิลิตี้ในเชิงพาณิชย์ เป็นแอปพลิเคชันบนเว็บและรวบรวมข้อมูลเว็บเบราว์เซอร์เพื่อกำหนดเป้าหมายโฆษณาโดยเฉพาะป๊อปอัป

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

  • Rootkit - รูทคิทเป็นซอฟต์แวร์ที่แฮ็กเกอร์ใช้เพื่อเข้าถึงระดับผู้ดูแลระบบไปยังคอมพิวเตอร์ / เครือข่ายที่ติดตั้งผ่านรหัสผ่านที่ขโมยมาหรือใช้ประโยชน์จากช่องโหว่ของระบบโดยที่เหยื่อไม่รู้ตัว

มาตรการป้องกัน

สามารถใช้มาตรการต่อไปนี้เพื่อหลีกเลี่ยงการมีมัลแวร์ในระบบ -

  • ตรวจสอบให้แน่ใจว่าระบบปฏิบัติการและแอพพลิเคชั่นทันสมัยด้วยแพตช์ / อัพเดต

  • อย่าเปิดอีเมลแปลก ๆ โดยเฉพาะอีเมลที่มีไฟล์แนบ

  • เมื่อคุณดาวน์โหลดจากอินเทอร์เน็ตโปรดตรวจสอบสิ่งที่คุณติดตั้งอยู่เสมอ อย่าเพียงแค่คลิกตกลงเพื่อปิดหน้าต่างป๊อปอัป ตรวจสอบผู้เผยแพร่ก่อนที่คุณจะติดตั้งแอปพลิเคชัน

  • ติดตั้งซอฟต์แวร์ป้องกันไวรัส

  • ตรวจสอบให้แน่ใจว่าคุณสแกนและอัปเดตโปรแกรมป้องกันไวรัสเป็นประจำ

  • ติดตั้งไฟร์วอลล์

  • เปิดใช้งานและใช้คุณสมบัติด้านความปลอดภัยที่เบราว์เซอร์และแอปพลิเคชันให้มาเสมอ

ซอฟต์แวร์ป้องกันมัลแวร์

ซอฟต์แวร์ต่อไปนี้ช่วยลบมัลแวร์ออกจากระบบ -

  • Microsoft Security Essentials
  • Microsoft Windows Defender
  • AVG Internet Security
  • Spybot - ค้นหาและทำลาย
  • Avast! Home Edition สำหรับการใช้งานส่วนตัว
  • Panda Internet Security
  • MacScan สำหรับ Mac OS และ Mac OS X

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

โปรโตคอล HTTP

Hypertext Transfer Protocol (HTTP) เป็นโปรโตคอลระดับแอปพลิเคชันสำหรับระบบข้อมูลแบบกระจายการทำงานร่วมกันและไฮเปอร์มีเดีย นี่เป็นรากฐานสำหรับการสื่อสารข้อมูลสำหรับเวิลด์ไวด์เว็บตั้งแต่ปี 1990 HTTP เป็นโปรโตคอลทั่วไปและไม่มีสถานะซึ่งสามารถใช้เพื่อวัตถุประสงค์อื่น ๆ ได้เช่นกันโดยใช้ส่วนขยายของวิธีการร้องขอรหัสข้อผิดพลาดและส่วนหัว

โดยพื้นฐานแล้ว HTTP เป็นโปรโตคอลการสื่อสารที่ใช้ TCP / IP ซึ่งใช้ในการส่งข้อมูลเช่นไฟล์ HTML ไฟล์รูปภาพผลการสืบค้นเป็นต้นทางเว็บ เป็นวิธีที่เป็นมาตรฐานสำหรับคอมพิวเตอร์ในการสื่อสารระหว่างกัน ข้อกำหนด HTTP ระบุวิธีการส่งข้อมูลที่ร้องขอของไคลเอ็นต์ไปยังเซิร์ฟเวอร์และเซิร์ฟเวอร์ตอบสนองต่อคำขอเหล่านี้อย่างไร

คุณสมบัติพื้นฐาน

มีคุณสมบัติพื้นฐานสามประการดังต่อไปนี้ซึ่งทำให้ HTTP เป็นโปรโตคอลที่เรียบง่าย แต่ทรงพลัง -

  • HTTP is connectionless- ไคลเอนต์ HTTP กล่าวคือเบราว์เซอร์เริ่มต้นคำขอ HTTP หลังจากทำการร้องขอไคลเอนต์จะยกเลิกการเชื่อมต่อจากเซิร์ฟเวอร์และรอการตอบกลับ เซิร์ฟเวอร์ประมวลผลคำขอและสร้างการเชื่อมต่อกับไคลเอนต์อีกครั้งเพื่อส่งการตอบกลับกลับ

  • HTTP is media independent- HTTP สามารถส่งข้อมูลประเภทใดก็ได้ตราบเท่าที่ทั้งไคลเอนต์และเซิร์ฟเวอร์รู้วิธีจัดการกับเนื้อหาข้อมูล สิ่งนี้จำเป็นสำหรับไคลเอนต์และเซิร์ฟเวอร์เพื่อระบุประเภทเนื้อหาโดยใช้ประเภท MIME ที่เหมาะสม

  • HTTP is stateless- HTTP เป็นแบบไร้การเชื่อมต่อและนี่เป็นผลลัพธ์โดยตรงที่ HTTP เป็นโปรโตคอลไร้รัฐ เซิร์ฟเวอร์และไคลเอนต์จะรับรู้ซึ่งกันและกันในระหว่างการร้องขอปัจจุบันเท่านั้น หลังจากนั้นทั้งคู่ก็ลืมเกี่ยวกับกันและกัน เนื่องจากลักษณะของโปรโตคอลนี้ทั้งไคลเอนต์และเบราว์เซอร์ไม่สามารถเก็บข้อมูลระหว่างคำขอต่างๆในหน้าเว็บได้

HTTP / 1.0 ใช้การเชื่อมต่อใหม่สำหรับการแลกเปลี่ยนคำขอ / การตอบกลับแต่ละรายการในขณะที่การเชื่อมต่อ HTTP / 1.1 อาจใช้สำหรับการแลกเปลี่ยนคำขอ / การตอบกลับอย่างน้อยหนึ่งรายการ

สถาปัตยกรรม

แผนภาพต่อไปนี้แสดงสถาปัตยกรรมพื้นฐานของเว็บแอปพลิเคชันและแสดงตำแหน่งที่ HTTP อยู่ -

โปรโตคอล HTTP เป็นโปรโตคอลการร้องขอ / การตอบสนองตามสถาปัตยกรรมไคลเอนต์ / เซิร์ฟเวอร์ที่เว็บเบราว์เซอร์โรบ็อตและเครื่องมือค้นหา ฯลฯ ทำหน้าที่เป็นไคลเอนต์ HTTP และเว็บเซิร์ฟเวอร์ทำหน้าที่เป็นเซิร์ฟเวอร์

  • Client - ไคลเอนต์ HTTP ส่งคำขอไปยังเซิร์ฟเวอร์ในรูปแบบของวิธีการร้องขอ URI และเวอร์ชันโปรโตคอลตามด้วยข้อความคล้าย MIME ที่มีตัวปรับเปลี่ยนคำขอข้อมูลไคลเอ็นต์และเนื้อหาที่เป็นไปได้ผ่านการเชื่อมต่อ TCP / IP

  • Server - เซิร์ฟเวอร์ HTTP ตอบสนองด้วยบรรทัดสถานะรวมถึงเวอร์ชันโปรโตคอลของข้อความและความสำเร็จหรือรหัสข้อผิดพลาดตามด้วยข้อความคล้าย MIME ที่มีข้อมูลเซิร์ฟเวอร์ข้อมูลเมตาของเอนทิตีและเนื้อหาของเอนทิตีที่เป็นไปได้

HTTP - ข้อเสีย

  • HTTP ไม่ใช่โปรโตคอลที่ปลอดภัยอย่างสมบูรณ์

  • HTTP ใช้พอร์ต 80 เป็นพอร์ตเริ่มต้นสำหรับการสื่อสาร

  • HTTP ทำงานที่ Application Layer จำเป็นต้องสร้างการเชื่อมต่อหลายรายการสำหรับการถ่ายโอนข้อมูลซึ่งจะเพิ่มค่าใช้จ่ายในการดูแลระบบ

  • ไม่จำเป็นต้องมีการเข้ารหัส / ใบรับรองดิจิทัลสำหรับการใช้ HTTP

รายละเอียดโปรโตคอล HTTP

เพื่อทำความเข้าใจเกี่ยวกับ HTTP Protocol แบบเจาะลึกให้คลิกที่ลิงค์ด้านล่าง

  • HTTP Parameters

  • HTTP Messages

  • HTTP Requests

  • HTTP Responses

  • HTTP Methods

  • HTTP Status Codes

  • HTTP Header Fields

  • HTTP Security

HTTPS (Hypertext Transfer Protocol ผ่าน Secure Socket Layer) หรือ HTTP ผ่าน SSL เป็นเว็บโปรโตคอลที่พัฒนาโดย Netscape ไม่ใช่โปรโตคอล แต่เป็นเพียงผลของการวางเลเยอร์ HTTP ไว้ด้านบนของ SSL / TLS (Secure Socket Layer / Transport Layer Security)

ในระยะสั้น HTTPS = HTTP + SSL

เมื่อใดที่จำเป็นต้องใช้ HTTPS

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

โปรโตคอล Https ที่ใช้ในสถานการณ์ต่อไปนี้ -

  • เว็บไซต์ธนาคาร
  • ช่องทางการชำระเงิน
  • เว็บไซต์ช้อปปิ้ง
  • หน้าเข้าสู่ระบบทั้งหมด
  • แอปอีเมล

การทำงานพื้นฐานของ HTTPS

  • ต้องใช้คีย์สาธารณะและใบรับรองที่ลงนามสำหรับเซิร์ฟเวอร์ในโปรโตคอล HTTPS

  • ลูกค้าร้องขอเพจ https: //

  • เมื่อใช้การเชื่อมต่อ https เซิร์ฟเวอร์จะตอบสนองต่อการเชื่อมต่อเริ่มต้นโดยเสนอรายการวิธีการเข้ารหัสที่เว็บเซิร์ฟเวอร์รองรับ

  • ในการตอบสนองไคลเอ็นต์จะเลือกวิธีการเชื่อมต่อและไคลเอนต์และใบรับรองการแลกเปลี่ยนเซิร์ฟเวอร์เพื่อพิสูจน์ตัวตนของพวกเขา

  • หลังจากเสร็จสิ้นทั้งเว็บเซิร์ฟเวอร์และไคลเอนต์จะแลกเปลี่ยนข้อมูลที่เข้ารหัสหลังจากแน่ใจว่าทั้งสองใช้คีย์เดียวกันและการเชื่อมต่อถูกปิด

  • สำหรับการโฮสต์การเชื่อมต่อ https เซิร์ฟเวอร์ต้องมีใบรับรองคีย์สาธารณะซึ่งจะฝังข้อมูลสำคัญพร้อมกับการยืนยันตัวตนของเจ้าของคีย์

  • ใบรับรองเกือบทั้งหมดได้รับการตรวจสอบโดยบุคคลที่สามเพื่อให้ลูกค้ามั่นใจได้ว่าคีย์นั้นปลอดภัยเสมอ

การเข้ารหัสและถอดรหัสคืออะไร?

การเข้ารหัสคือกระบวนการใส่ลำดับของอักขระเช่นตัวอักษรตัวเลขและอักขระพิเศษอื่น ๆ ลงในรูปแบบเฉพาะเพื่อการส่งที่มีประสิทธิภาพ

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

การเข้ารหัสและถอดรหัสใช้ในการสื่อสารและการจัดเก็บข้อมูล ไม่ควรใช้การเข้ารหัสเพื่อขนส่งข้อมูลที่ละเอียดอ่อน

การเข้ารหัส URL

URL สามารถส่งผ่านอินเทอร์เน็ตโดยใช้ชุดอักขระ ASCII เท่านั้นและมีบางกรณีที่ URL มีอักขระพิเศษนอกเหนือจากอักขระ ASCII จำเป็นต้องเข้ารหัส URL ไม่มีช่องว่างและแทนที่ด้วยเครื่องหมายบวก (+) หรือด้วย% 20

การเข้ารหัส ASCII

เบราว์เซอร์ (ฝั่งไคลเอ็นต์) จะเข้ารหัสอินพุตตามชุดอักขระที่ใช้ในเว็บเพจและชุดอักขระเริ่มต้นใน HTML5 คือ UTF-8

ตารางต่อไปนี้แสดงสัญลักษณ์ ASCII ของอักขระและสัญลักษณ์ที่เท่ากันและสุดท้ายแทนที่ซึ่งสามารถใช้ใน URL ก่อนส่งต่อไปยังเซิร์ฟเวอร์ -

ASCII สัญลักษณ์ เปลี่ยน
<32   เข้ารหัสด้วย% xx โดยที่ xx เป็นตัวแทนฐานสิบหกของอักขระ
32 พื้นที่ + หรือ% 20
33 ! % 21
34 " % 22
35 # % 23
36 $ % 24
37 % % 25
38 & % 26
39 ' % 27
40 ( % 28
41 ) % 29
42 * *
43 + % 2B
44 , % 2C
45 - -
46 . .
47 / % 2F
48 0 0
49 1 1
50 2 2
51 3 3
52 4 4
53 5 5
54 6 6
55 7 7
56 8 8
57 9 9
58 : % 3A
59 ; % 3B
60 > % 3C
61 = % 3D
62 > % 3E
63 เหรอ? % 3F
64 @ % 40
65
66
67
68
69
70
71
72
73 ผม ผม
74 เจ เจ
75 เค เค
76
77
78
79 โอ โอ
80
81 ถาม ถาม
82
83
84 ที ที
85 ยู ยู
86 วี วี
87
88 X X
89
90 Z Z
91 [ % 5B
92 \ % 5C
93 ] % 5D
94 ^ % 5E
95 _ _
96 ` 60%
97
98
99
100
101
102
103
104
105 ผม ผม
106
107 k k
108
109
110 n n
111 o o
112
113 q q
114
115 เอส เอส
116 t t
117 ยู ยู
118 v v
119
120 x x
121
122 z z
123 { % 7B
124 | % 7C
125 } % 7 ด
126 ~ % 7E
127   % 7F
> 127   เข้ารหัสด้วย% xx โดยที่ xx เป็นตัวแทนฐานสิบหกของอักขระ

Cryptography คืออะไร?

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

ข้อมูลที่สามารถอ่านและเข้าใจได้โดยไม่ต้องมีมาตรการพิเศษใด ๆ เรียกว่า plaintextในขณะที่วิธีการปลอมแปลงข้อความธรรมดาเพื่อซ่อนสสารนั้นเรียกว่า encryption.

ข้อความธรรมดาที่เข้ารหัสเรียกว่าข้อความเข้ารหัสและกระบวนการเปลี่ยนข้อมูลที่เข้ารหัสกลับเป็นข้อความธรรมดาเรียกว่า decryption.

  • ศาสตร์แห่งการวิเคราะห์และทำลายการสื่อสารที่ปลอดภัยเรียกว่า cryptanalysis คนที่ดำเนินการเช่นเดียวกันหรือที่เรียกว่าผู้โจมตี

  • การเข้ารหัสอาจมีความแข็งแกร่งหรืออ่อนแอและความแข็งแกร่งจะวัดได้จากเวลาและทรัพยากรที่ต้องใช้ในการกู้คืนข้อความธรรมดาที่แท้จริง

  • ดังนั้นจึงต้องใช้เครื่องมือถอดรหัสที่เหมาะสมในการถอดรหัสข้อความเข้ารหัสที่แข็งแกร่ง

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

  • เนื่องจากพลังการประมวลผลเพิ่มขึ้นทุกวันเราจึงต้องทำให้อัลกอริทึมการเข้ารหัสมีความแข็งแกร่งมากเพื่อปกป้องข้อมูลและข้อมูลสำคัญจากผู้โจมตี

การเข้ารหัสทำงานอย่างไร

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

ดังนั้นข้อมูลที่เข้ารหัสจึงขึ้นอยู่กับพารามิเตอร์สองตัวอย่างสมบูรณ์เช่นความแข็งแกร่งของอัลกอริทึมการเข้ารหัสและความลับของคีย์

เทคนิคการเข้ารหัส

Symmetric Encryption- การเข้ารหัสแบบเดิมหรือที่เรียกว่าการเข้ารหัสแบบเดิมเป็นเทคนิคที่ใช้เพียงคีย์เดียวสำหรับทั้งการเข้ารหัสและการถอดรหัส ตัวอย่างเช่น DES, อัลกอริทึม Triple DES, MARS โดย IBM, RC2, RC4, RC5, RC6

Asymmetric Encryption- เป็นการเข้ารหัสคีย์สาธารณะที่ใช้คู่ของคีย์ในการเข้ารหัส: คีย์สาธารณะสำหรับเข้ารหัสข้อมูลและคีย์ส่วนตัวสำหรับการถอดรหัส มีการเผยแพร่คีย์สาธารณะให้กับผู้คนในขณะที่เก็บคีย์ส่วนตัวไว้เป็นความลับ ตัวอย่างเช่น RSA, Digital Signature Algorithm (DSA), Elgamal

Hashing- การแฮชเป็นการเข้ารหัสทางเดียวซึ่งจะสร้างเอาต์พุตที่มีสัญญาณรบกวนที่ไม่สามารถย้อนกลับได้หรืออย่างน้อยก็ไม่สามารถย้อนกลับได้อย่างง่ายดาย ตัวอย่างเช่นอัลกอริทึม MD5 ใช้เพื่อสร้างใบรับรองดิจิทัลลายเซ็นดิจิทัลการจัดเก็บรหัสผ่านการตรวจสอบการสื่อสาร ฯลฯ

นโยบายแหล่งกำเนิดเดียวกัน (SOP) เป็นแนวคิดสำคัญในรูปแบบการรักษาความปลอดภัยของเว็บแอปพลิเคชัน

นโยบายแหล่งกำเนิดเดียวกันคืออะไร?

ตามนโยบายนี้อนุญาตให้สคริปต์ทำงานบนเพจที่มาจากไซต์เดียวกันซึ่งสามารถรวมกันได้ดังต่อไปนี้ -

  • Domain
  • Protocol
  • Port

ตัวอย่าง

เหตุผลเบื้องหลังพฤติกรรมนี้คือความปลอดภัย หากคุณมีtry.comในหน้าต่างเดียวและgmail.comในหน้าต่างอื่นแสดงว่าคุณไม่ต้องการให้สคริปต์จาก try.com เข้าถึงหรือแก้ไขเนื้อหาของ gmail.com หรือเรียกใช้การดำเนินการในบริบทของ gmail ในนามของคุณ

ด้านล่างนี้คือหน้าเว็บที่มาจากแหล่งกำเนิดเดียวกัน ตามที่อธิบายไว้ก่อนหน้านี้ต้นกำเนิดเดียวกันจะพิจารณาโดเมน / โปรโตคอล / พอร์ต

  • http://website.com
  • http://website.com/
  • http://website.com/my/contact.html

ด้านล่างนี้คือหน้าเว็บที่มาจากแหล่งกำเนิดอื่น

  • http://www.site.co.uk (โดเมนอื่น)
  • http://site.org (โดเมนอื่น)
  • https://site.com (โปรโตคอลอื่น)
  • http://site.com:8080 (พอร์ตอื่น)

ข้อยกเว้นนโยบาย Origin เดียวกันสำหรับ IE

Internet Explorer มีข้อยกเว้นหลักสองประการสำหรับ SOP

  • อันแรกเกี่ยวข้องกับ 'Trusted Zones' หากโดเมนทั้งสองอยู่ในโซนที่มีความน่าเชื่อถือสูงนโยบายจุดเริ่มต้นเดียวกันจะไม่สามารถใช้ได้อย่างสมบูรณ์

  • ข้อยกเว้นประการที่สองใน IE เกี่ยวข้องกับพอร์ต IE ไม่รวมพอร์ตไว้ในนโยบายแหล่งกำเนิดเดียวกันดังนั้น http://website.com และ http://wesite.com:4444 จึงได้รับการพิจารณาจากแหล่งที่มาเดียวกันและไม่มีการใช้ข้อ จำกัด ใด ๆ

คุกกี้คืออะไร?

คุกกี้คือข้อมูลชิ้นเล็ก ๆ ที่เว็บเซิร์ฟเวอร์ส่งมาเพื่อจัดเก็บบนเว็บเบราว์เซอร์เพื่อให้เบราว์เซอร์อ่านได้ในภายหลัง วิธีนี้เบราว์เซอร์จะจดจำข้อมูลส่วนบุคคลบางอย่าง หากแฮ็กเกอร์ยึดข้อมูลคุกกี้อาจนำไปสู่ปัญหาด้านความปลอดภัย

คุณสมบัติของคุกกี้

นี่คือคุณสมบัติที่สำคัญบางประการของคุกกี้ -

  • โดยปกติจะเป็นไฟล์ข้อความขนาดเล็กโดยมีแท็ก ID ที่เก็บไว้ในไดเร็กทอรีเบราว์เซอร์ของคอมพิวเตอร์ของคุณ

  • ใช้โดยนักพัฒนาเว็บเพื่อช่วยให้ผู้ใช้ไปยังเว็บไซต์ได้อย่างมีประสิทธิภาพและทำหน้าที่บางอย่าง

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

  • คุกกี้เป็นสิ่งที่หลีกเลี่ยงไม่ได้สำหรับเว็บไซต์ที่มีฐานข้อมูลขนาดใหญ่จำเป็นต้องเข้าสู่ระบบมีธีมที่ปรับแต่งได้

เนื้อหาคุกกี้

คุกกี้มีข้อมูลต่อไปนี้ -

  • ชื่อของเซิร์ฟเวอร์ที่คุกกี้ถูกส่งมา
  • อายุการใช้งานของคุกกี้
  • ค่า - โดยปกติจะเป็นตัวเลขเฉพาะที่สร้างขึ้นแบบสุ่ม

ประเภทของคุกกี้

  • Session Cookies- คุกกี้เหล่านี้เป็นคุกกี้ชั่วคราวซึ่งจะถูกลบเมื่อผู้ใช้ปิดเบราว์เซอร์ แม้ว่าผู้ใช้จะเข้าสู่ระบบอีกครั้งคุกกี้ใหม่สำหรับเซสชันนั้นจะถูกสร้างขึ้น

  • Persistent cookies- คุกกี้เหล่านี้ยังคงอยู่ในฮาร์ดดิสก์ไดรฟ์เว้นแต่ผู้ใช้จะล้างออกหรือหมดอายุ การหมดอายุของคุกกี้ขึ้นอยู่กับระยะเวลาที่คุกกี้จะอยู่ได้

คุกกี้ทดสอบ

นี่คือวิธีทดสอบคุกกี้ -

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

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

  • Removing Cookies - ลบคุกกี้ทั้งหมดสำหรับเว็บไซต์และตรวจสอบว่าเว็บไซต์มีปฏิกิริยาอย่างไร

  • Cross-Browser Compatibility - สิ่งสำคัญคือต้องตรวจสอบว่าคุกกี้ถูกเขียนอย่างถูกต้องบนเบราว์เซอร์ที่รองรับทั้งหมดจากหน้าใด ๆ ที่เขียนคุกกี้

  • Editing Cookies- หากแอปพลิเคชันใช้คุกกี้เพื่อเก็บข้อมูลการเข้าสู่ระบบในฐานะผู้ทดสอบเราควรลองเปลี่ยนผู้ใช้ในคุกกี้หรือแถบที่อยู่เป็นผู้ใช้ที่ถูกต้องอื่น การแก้ไขคุกกี้ไม่ควรให้คุณลงชื่อเข้าใช้บัญชีผู้ใช้อื่น

การดูและแก้ไขคุกกี้

เบราว์เซอร์สมัยใหม่รองรับการดู / แก้ไขคุกกี้ที่แจ้งภายในเบราว์เซอร์เอง มีปลั๊กอินสำหรับ mozilla / chrome ที่เราสามารถทำการแก้ไขได้สำเร็จ

  • แก้ไขปลั๊กอินคุกกี้สำหรับ Firefox

  • แก้ไขปลั๊กอินคุกกี้นี้สำหรับ Chrome

ขั้นตอนควรดำเนินการเพื่อแก้ไขคุกกี้ -

  • ดาวน์โหลดปลั๊กอินสำหรับ Chrome จากที่นี่

  • แก้ไขค่าคุกกี้เพียงแค่เข้าถึงปลั๊กอิน "แก้ไขคุกกี้นี้" จาก chrome ดังที่แสดงด้านล่าง

มีวิธีการ / แนวทางต่างๆที่เราสามารถใช้เป็นข้อมูลอ้างอิงในการโจมตีได้

Web Application - PenTesting Methodologies

เราสามารถคำนึงถึงมาตรฐานต่อไปนี้ในขณะที่พัฒนารูปแบบการโจมตี

ในรายการต่อไปนี้ OWASP มีการใช้งานมากที่สุดและมีผู้ร่วมให้ข้อมูลจำนวนมาก เราจะมุ่งเน้นไปที่เทคนิค OWASP ซึ่งทีมพัฒนาแต่ละทีมจะต้องพิจารณาก่อนออกแบบเว็บแอป

  • PTES - มาตรฐานการดำเนินการทดสอบการเจาะ

  • OSSTMM - คู่มือวิธีการทดสอบความปลอดภัยโอเพ่นซอร์ส

  • เทคนิคการทดสอบ OWASP - เปิด Web Application Security Protocol

OWASP 10 อันดับแรก

ทีม Open Web Application Security Protocol ได้เปิดเผยช่องโหว่ 10 อันดับแรกที่แพร่หลายมากขึ้นในเว็บในช่วงไม่กี่ปีที่ผ่านมา ด้านล่างนี้คือรายการข้อบกพร่องด้านความปลอดภัยที่แพร่หลายมากขึ้นในแอปพลิเคชันบนเว็บ

ใบสมัคร - ลงมือทำ

เพื่อให้เข้าใจเทคนิคแต่ละอย่างให้เราทำงานกับแอปพลิเคชันตัวอย่าง เราจะทำการโจมตี 'WebGoat' ซึ่งเป็นแอปพลิเคชัน J2EE ซึ่งพัฒนาขึ้นอย่างชัดเจนโดยมีข้อบกพร่องด้านความปลอดภัยเพื่อการเรียนรู้

สามารถดูรายละเอียดทั้งหมดเกี่ยวกับโครงการ webgoat ได้ https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project. ในการดาวน์โหลดแอปพลิเคชัน WebGoat ให้ไปที่https://github.com/WebGoat/WebGoat/wiki/Installation-(WebGoat-6.0) และส่วนดาวน์โหลด goto

ในการติดตั้งแอปพลิเคชันที่ดาวน์โหลดมาก่อนอื่นให้แน่ใจว่าคุณไม่มีแอปพลิเคชันใด ๆ ที่ทำงานบนพอร์ต 8080 สามารถติดตั้งได้โดยใช้คำสั่งเดียว - java -jar WebGoat-6.0.1-war-exec.jar สำหรับรายละเอียดเพิ่มเติมโปรดไปที่การติดตั้ง WebGoat

โพสต์การติดตั้งเราควรจะสามารถเข้าถึงแอปพลิเคชันได้โดยไปที่ http://localhost:8080/WebGoat/attack และหน้าจะแสดงดังที่แสดงด้านล่าง

เราสามารถใช้ข้อมูลประจำตัวของผู้เยี่ยมชมหรือผู้ดูแลระบบตามที่ปรากฏในหน้าล็อกอิน

เว็บพร็อกซี

ในการสกัดกั้นการรับส่งข้อมูลระหว่างไคลเอนต์ (เบราว์เซอร์) และเซิร์ฟเวอร์ (ระบบที่ Webgoat Application โฮสต์อยู่ในกรณีของเรา) เราจำเป็นต้องใช้เว็บพร็อกซี เราจะใช้ Burp Proxy ที่สามารถดาวน์โหลดได้จากhttps://portswigger.net/burp/download.html

ก็เพียงพอแล้วหากคุณดาวน์โหลดชุดเรอรุ่นฟรีดังที่แสดงด้านล่าง

การกำหนดค่า Burp Suite

Burp Suite เป็นเว็บพร็อกซีที่สามารถดักจับข้อมูลแต่ละแพ็กเก็ตที่เบราว์เซอร์และเว็บเซิร์ฟเวอร์ส่งและรับได้ สิ่งนี้ช่วยให้เราแก้ไขเนื้อหาก่อนที่ไคลเอนต์จะส่งข้อมูลไปยังเว็บเซิร์ฟเวอร์

Step 1- แอปติดตั้งบนพอร์ต 8080 และติดตั้ง Burp บนพอร์ต 8181 ดังที่แสดงด้านล่าง เปิด Burp suite และทำการตั้งค่าต่อไปนี้เพื่อเปิดใช้งานในพอร์ต 8181 ดังที่แสดงด้านล่าง

Step 2- เราควรตรวจสอบให้แน่ใจว่า Burp กำลังฟังพอร์ต # 8080 ที่มีการติดตั้งแอปพลิเคชันเพื่อให้ Burp suite สามารถดักฟังการรับส่งข้อมูลได้ การตั้งค่านี้ควรทำในแท็บขอบเขตของ Burp Suite ดังที่แสดงด้านล่าง

Step 3- จากนั้นทำการตั้งค่าพร็อกซีเบราว์เซอร์ของคุณเพื่อฟังพอร์ต 8181 (พอร์ต Burp Suite) ดังนั้นเราจึงได้กำหนดค่าเว็บพร็อกซีเพื่อสกัดกั้นการรับส่งข้อมูลระหว่างไคลเอนต์ (เบราว์เซอร์) และเซิร์ฟเวอร์ (เว็บเซิร์ฟเวอร์) ดังที่แสดงด้านล่าง -

Step 4 - ภาพรวมของการกำหนดค่าแสดงอยู่ด้านล่างด้วยความช่วยเหลือของแผนภาพเวิร์กโฟลว์อย่างง่ายดังที่แสดงด้านล่าง

เทคนิคการฉีดประกอบด้วยการฉีดแบบสอบถาม SQL หรือคำสั่งโดยใช้ช่องป้อนข้อมูลของแอปพลิเคชัน

เว็บแอปพลิเคชัน - การฉีด

การแทรก SQL ที่ประสบความสำเร็จสามารถอ่านแก้ไขข้อมูลที่ละเอียดอ่อนจากฐานข้อมูลและยังสามารถลบข้อมูลออกจากฐานข้อมูล นอกจากนี้ยังช่วยให้แฮ็กเกอร์สามารถดำเนินการดูแลระบบบนฐานข้อมูลเช่นปิดฐานข้อมูล DBMS / วางฐานข้อมูล

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

ตัวอย่าง

แอปพลิเคชันใช้ข้อมูลที่ไม่น่าเชื่อถือในการสร้างการเรียก SQL ที่มีช่องโหว่ดังต่อไปนี้ -

String query = "SELECT * FROM EMP WHERE EMPID = '" + request.getParameter("id") + "'";

Hands On

Step 1 - ไปที่พื้นที่ SQL Injection ของแอปพลิเคชันดังที่แสดงด้านล่าง

Step 2- ตามที่ระบุไว้ในแบบฝึกหัดนี้เราใช้ String SQL Injection เพื่อข้ามการพิสูจน์ตัวตน ใช้ SQL injection เพื่อเข้าสู่ระบบในฐานะเจ้านาย ('Neville') โดยไม่ต้องใช้รหัสผ่านที่ถูกต้อง ตรวจสอบว่าสามารถดูโปรไฟล์ของเนวิลล์ได้และมีฟังก์ชันทั้งหมดที่พร้อมใช้งาน (รวมถึงค้นหาสร้างและลบ)

Step 3 - เราจะใส่ SQL เพื่อให้เราสามารถข้ามรหัสผ่านได้โดยส่งพารามิเตอร์เป็น 'a' = 'a' หรือ 1 = 1

Step 4 - Post Exploitation เราสามารถเข้าสู่ระบบในฐานะ Neville ที่เป็น Admin ได้ตามที่แสดงด้านล่าง

การป้องกัน SQL Injection

มีหลายวิธีในการป้องกันการฉีด SQL เมื่อนักพัฒนาเขียนโค้ดพวกเขาควรตรวจสอบให้แน่ใจว่าพวกเขาจัดการอักขระพิเศษตามนั้น มีสูตรโกง / เทคนิคการป้องกันจาก OWASP ซึ่งเป็นแนวทางสำหรับนักพัฒนา

  • การใช้การสืบค้นแบบกำหนดพารามิเตอร์
  • การหลีกเลี่ยงอินพุตที่ผู้ใช้ให้มาทั้งหมด
  • เปิดใช้งาน Least Privilege สำหรับฐานข้อมูลสำหรับผู้ใช้ปลายทาง

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

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

ตัวอย่าง

An e-commerce application supports URL rewriting, putting session IDs in the URL −

http://example.com/sale/saleitems/jsessionid=2P0OC2JSNDLPSKHCJUN2JV/?item=laptop

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

Hands ON

Step 1- เข้าสู่ระบบ Webgoat และไปที่ส่วน 'ข้อบกพร่องการจัดการเซสชัน' ให้เราข้ามการพิสูจน์ตัวตนโดยการปลอมแปลงคุกกี้ ด้านล่างนี้คือภาพรวมของสถานการณ์

Step 2 - เมื่อเราเข้าสู่ระบบโดยใช้ข้อมูลประจำตัว webgoat / webgoat เราพบจาก Burp Suite ว่า JSESSION ID คือ C8F3177CCAFF380441ABF71090748F2E ในขณะที่ AuthCookie = 65432ubphcfx เมื่อตรวจสอบสิทธิ์สำเร็จ

Step 3 - เมื่อเราเข้าสู่ระบบโดยใช้ข้อมูลประจำตัวด้าน / ด้านเราพบจาก Burp Suite ว่า JSESSION ID คือ C8F3177CCAFF380441ABF71090748F2E ในขณะที่ AuthCookie = 65432udfqtb เมื่อตรวจสอบสิทธิ์สำเร็จ

Step 4- ตอนนี้เราต้องวิเคราะห์รูปแบบ AuthCookie ครึ่งแรก '65432' เป็นเรื่องปกติสำหรับการตรวจสอบสิทธิ์ทั้งสอง ดังนั้นตอนนี้เราสนใจที่จะวิเคราะห์ส่วนสุดท้ายของค่า authcookie เช่น - ubphcfx สำหรับผู้ใช้ webgoat และ udfqtb สำหรับผู้ใช้ด้านตามลำดับ

Step 5- หากเราพิจารณาค่า AuthCookie อย่างละเอียดส่วนสุดท้ายจะมีความยาวเท่ากับชื่อผู้ใช้ ดังนั้นจึงเห็นได้ชัดว่าชื่อผู้ใช้ถูกใช้ด้วยวิธีการเข้ารหัสบางอย่าง จากการทดลองและข้อผิดพลาด / กลไกกำลังดุร้ายเราพบว่าหลังจากย้อนกลับชื่อผู้ใช้ webgoat; เราลงท้ายด้วย taogbew จากนั้นตัวอักษร before คือสิ่งที่ใช้เป็น AuthCookie คือ ubphcfx

Step 6- หากเราส่งผ่านค่าคุกกี้นี้และแจ้งให้เราทราบว่าเกิดอะไรขึ้น เมื่อตรวจสอบสิทธิ์เป็น webgoat ของผู้ใช้ให้เปลี่ยนค่า AuthCookie เพื่อเยาะเย้ยผู้ใช้ Alice โดยค้นหา AuthCookie สำหรับสิ่งเดียวกันโดยทำตามขั้นตอนที่ # 4 และขั้นตอนที่ 5

การป้องกันกลไก

  • พัฒนาการตรวจสอบความถูกต้องและการควบคุมการจัดการเซสชันเพื่อให้เป็นไปตามข้อกำหนดการรับรองความถูกต้องและการจัดการเซสชันทั้งหมดที่กำหนดไว้ในมาตรฐานการตรวจสอบความปลอดภัยของแอปพลิเคชัน OWASP

  • นักพัฒนาควรตรวจสอบให้แน่ใจว่าพวกเขาหลีกเลี่ยงข้อบกพร่อง XSS ที่สามารถใช้เพื่อขโมยรหัสเซสชัน

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

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

ประเภทของ XSS

  • Stored XSS - XSS ที่เก็บไว้หรือที่เรียกว่า XSS ถาวรจะเกิดขึ้นเมื่อข้อมูลของผู้ใช้ถูกเก็บไว้บนเซิร์ฟเวอร์เป้าหมายเช่นฐานข้อมูล / ฟอรัมข้อความ / ช่องแสดงความคิดเห็นเป็นต้นจากนั้นเหยื่อจะสามารถดึงข้อมูลที่เก็บไว้จากเว็บแอปพลิเคชันได้

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

  • DOM Based XSS - DOM Based XSS เป็นรูปแบบหนึ่งของ XSS เมื่อแหล่งที่มาของข้อมูลอยู่ใน DOM ซิงก์ก็อยู่ใน DOM เช่นกันและกระแสข้อมูลจะไม่ออกจากเบราว์เซอร์

ตัวอย่าง

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

http://www.webpage.org/task/Rule1?query=try

ผู้โจมตีแก้ไขพารามิเตอร์การสืบค้นในเบราว์เซอร์ของตนเป็น -

http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>

Hands ON

Step 1- เข้าสู่ระบบ Webgoat และไปที่ส่วน cross-site scripting (XSS) ให้เราทำการโจมตีแบบ Stored Cross-site Scripting (XSS) ด้านล่างนี้คือภาพรวมของสถานการณ์

Step 2- ตามสถานการณ์ให้เราเข้าสู่ระบบในฐานะทอมด้วยรหัสผ่าน 'ทอม' ตามที่กล่าวไว้ในสถานการณ์นั้นเอง คลิก 'ดูโปรไฟล์' และเข้าสู่โหมดแก้ไข เนื่องจากทอมเป็นผู้โจมตีให้เราฉีดสคริปต์ Java ลงในกล่องแก้ไขเหล่านั้น

<script> 
   alert("HACKED")
</script>

Step 3 - ทันทีที่การอัปเดตสิ้นสุดลงทอมจะได้รับกล่องแจ้งเตือนพร้อมข้อความ "แฮ็ก" ซึ่งหมายความว่าแอปมีช่องโหว่

Step 4 - ตามสถานการณ์เราจำเป็นต้องล็อกอินเป็นเจอร์รี่ (HR) และตรวจสอบว่าเจอร์รี่ได้รับผลกระทบจากสคริปต์ที่ฉีดเข้าไปหรือไม่

Step 5 - หลังจากเข้าสู่ระบบในฐานะเจอร์รี่แล้วให้เลือก "ทอม" และคลิก "ดูโปรไฟล์" ตามที่แสดงด้านล่าง

ในขณะที่ดูโปรไฟล์ของทอมจากบัญชีของเจอร์รี่เขาสามารถรับกล่องข้อความเดียวกันได้

Step 6 - กล่องข้อความนี้เป็นเพียงตัวอย่าง แต่ผู้โจมตีจริงสามารถดำเนินการได้มากกว่าการแสดงกล่องข้อความ

กลไกการป้องกัน

  • นักพัฒนาต้องตรวจสอบให้แน่ใจว่าพวกเขาหลีกเลี่ยงข้อมูลที่ไม่น่าเชื่อถือทั้งหมดตามบริบท HTML เช่นเนื้อหาแอตทริบิวต์ JavaScript CSS หรือ URL ที่ใส่ข้อมูลลงไป

  • สำหรับแอปพลิเคชันที่ต้องการอักขระพิเศษเป็นอินพุตควรมีกลไกการตรวจสอบความถูกต้องก่อนที่จะยอมรับว่าเป็นอินพุตที่ถูกต้อง

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

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

ตัวอย่าง

แอปใช้ข้อมูลที่ไม่ได้รับการยืนยันในการเรียก SQL ที่กำลังเข้าถึงข้อมูลบัญชี

String sqlquery = "SELECT * FROM useraccounts WHERE account = ?";
PreparedStatement st = connection.prepareStatement(sqlquery, ??);
st.setString( 1, request.getParameter("acct"));
ResultSet results = st.executeQuery( );

ผู้โจมตีแก้ไขพารามิเตอร์การสืบค้นในเบราว์เซอร์เพื่อชี้ไปที่ผู้ดูแลระบบ

http://webapp.com/app/accountInfo?acct=admin

Hands ON

Step 1- เข้าสู่ระบบ Webgoat และไปที่ส่วนข้อบกพร่องในการควบคุมการเข้าถึง เป้าหมายคือการดึงข้อมูล tomcat-users.xml โดยการนำทางไปยังเส้นทางที่ตั้งอยู่ ด้านล่างนี้คือภาพรวมของสถานการณ์

Step 2 - เส้นทางของไฟล์จะแสดงในฟิลด์ 'ไดเร็กทอรีปัจจุบันคือ' - C: \ Users \ userName $ \. extract \ webapps \ WebGoat \ lesson_plans \ en และเรายังทราบว่าไฟล์ tomcat-users.xml ถูกเก็บไว้ภายใต้ C: \ xampp \ tomcat \ conf

Step 3- เราจำเป็นต้องสำรวจจนสุดออกจากไดเร็กทอรีปัจจุบันและนำทางจาก C: \ Drive เราสามารถดำเนินการเช่นเดียวกันโดยการสกัดกั้นการจราจรโดยใช้ Burp Suite

Step 4 - หากความพยายามสำเร็จจะแสดง tomcat-users.xml พร้อมข้อความ "ขอแสดงความยินดีคุณทำบทเรียนนี้สำเร็จแล้ว"

กลไกการป้องกัน

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

  • นักพัฒนาควรใช้ผู้ใช้หรือเซสชันเดียวเท่านั้นสำหรับการอ้างอิงวัตถุทางอ้อม

  • ขอแนะนำให้ตรวจสอบการเข้าถึงก่อนใช้การอ้างอิงวัตถุโดยตรงจากแหล่งที่ไม่น่าเชื่อถือ

การกำหนดค่าความปลอดภัยผิดเกิดขึ้นเมื่อมีการกำหนดการใช้งานและดูแลการตั้งค่าความปลอดภัยเป็นค่าเริ่มต้น การรักษาความปลอดภัยที่ดีต้องการการกำหนดค่าที่ปลอดภัยที่กำหนดและปรับใช้สำหรับแอปพลิเคชันเว็บเซิร์ฟเวอร์เซิร์ฟเวอร์ฐานข้อมูลและแพลตฟอร์ม การปรับปรุงซอฟต์แวร์ให้ทันสมัยมีความสำคัญเท่าเทียมกัน

ตัวอย่าง

ตัวอย่างคลาสสิกของการกำหนดค่าความปลอดภัยผิดมีดังที่ระบุ -

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

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

  • เซิร์ฟเวอร์แอปมักจะมาพร้อมกับแอปตัวอย่างที่ไม่ปลอดภัย หากไม่ถูกลบออกจากเซิร์ฟเวอร์ที่ใช้งานจริงจะส่งผลให้เซิร์ฟเวอร์ของคุณบุกรุก

Hands ON

Step 1- เปิด Webgoat และไปที่ส่วนการกำหนดค่าที่ไม่ปลอดภัยและให้เราพยายามแก้ปัญหานั้น ภาพรวมของสิ่งเดียวกันอยู่ด้านล่าง -

Step 2- เราสามารถลองใช้ตัวเลือกต่างๆได้มากเท่าที่จะคิดได้ สิ่งที่เราต้องหา URL ของไฟล์ config และเรารู้ว่านักพัฒนาทำตามหลักการตั้งชื่อสำหรับไฟล์ config อาจเป็นอะไรก็ได้ที่ระบุไว้ด้านล่าง โดยปกติจะทำโดยเทคนิค BRUTE force

  • web.config
  • config
  • appname.config
  • conf

Step 3 - เมื่อลองใช้ตัวเลือกต่างๆเราพบว่า 'http://localhost:8080/WebGoat/conf'ประสบความสำเร็จ หน้าต่อไปนี้จะปรากฏขึ้นหากความพยายามสำเร็จ -

กลไกการป้องกัน

  • สภาพแวดล้อมการพัฒนา QA และการผลิตทั้งหมดดังกล่าวควรได้รับการกำหนดค่าให้เหมือนกันโดยใช้รหัสผ่านที่แตกต่างกันที่ใช้ในแต่ละสภาพแวดล้อมที่ไม่สามารถแฮ็กได้โดยง่าย

  • ตรวจสอบให้แน่ใจว่ามีการนำสถาปัตยกรรมแอ็พพลิเคชันที่แข็งแกร่งมาใช้ซึ่งให้การแยกระหว่างส่วนประกอบที่มีประสิทธิภาพและปลอดภัย

  • นอกจากนี้ยังสามารถลดความเป็นไปได้ของการโจมตีนี้ด้วยการสแกนอัตโนมัติและทำการตรวจสอบเป็นระยะ

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

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

ตัวอย่าง

ตัวอย่างคลาสสิกบางส่วนของการกำหนดค่าความปลอดภัยมีดังที่ระบุ -

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

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

Hands ON

Step 1- เปิด WebGoat และไปที่ส่วน "Insecure Storage" ภาพรวมของสิ่งเดียวกันจะแสดงอยู่ด้านล่าง

Step 2- ป้อนชื่อผู้ใช้และรหัสผ่าน ถึงเวลาแล้วที่จะเรียนรู้วิธีการเข้ารหัสและการเข้ารหัสแบบต่างๆที่เราพูดถึงก่อนหน้านี้

กลไกการป้องกัน

  • ขอแนะนำว่าอย่าจัดเก็บข้อมูลที่ละเอียดอ่อนโดยไม่จำเป็นและควรคัดลอกโดยเร็วที่สุดหากไม่จำเป็นอีกต่อไป

  • เป็นสิ่งสำคัญเพื่อให้แน่ใจว่าเรามีการใช้อัลกอริธึมการเข้ารหัสที่แข็งแกร่งและได้มาตรฐานและมีการจัดการคีย์ที่เหมาะสม

  • นอกจากนี้ยังสามารถหลีกเลี่ยงได้โดยการปิดใช้งานการเติมข้อความอัตโนมัติในแบบฟอร์มที่รวบรวมข้อมูลที่ละเอียดอ่อนเช่นรหัสผ่านและปิดใช้งานการแคชสำหรับหน้าที่มีข้อมูลที่ละเอียดอ่อน

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

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

ตัวอย่าง

นี่คือตัวอย่างคลาสสิกของ Missing Function Level Access Control -

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

' Below URL might be accessible to an authenticated user
http://website.com/app/standarduserpage

' A NON Admin user is able to access admin page without authorization.
http://website.com/app/admin_page

Hands ON

Step 1 - ให้เราเข้าสู่ระบบในฐานะผู้จัดการบัญชีโดยดูรายชื่อผู้ใช้และสิทธิ์การเข้าถึงก่อน

Step 2 - เมื่อลองใช้ชุดค่าผสมต่างๆเราพบว่า Larry สามารถเข้าถึงผู้จัดการบัญชีทรัพยากรได้

กลไกการป้องกัน

  • กลไกการพิสูจน์ตัวตนควรปฏิเสธการเข้าถึงทั้งหมดตามค่าเริ่มต้นและให้การเข้าถึงบทบาทเฉพาะสำหรับทุกฟังก์ชัน

  • ในแอปพลิเคชันที่ใช้เวิร์กโฟลว์ตรวจสอบสถานะของผู้ใช้ก่อนอนุญาตให้เข้าถึงทรัพยากรใด ๆ

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

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

ตัวอย่าง

นี่คือตัวอย่างคลาสสิกของ CSRF -

Step 1 - สมมติว่าแอปพลิเคชันที่มีช่องโหว่จะส่งคำขอเปลี่ยนสถานะเป็นข้อความธรรมดาโดยไม่มีการเข้ารหัสใด ๆ

http://bankx.com/app?action=transferFund&amount=3500&destinationAccount=4673243243

Step 2 - ตอนนี้แฮ็กเกอร์สร้างคำขอที่โอนเงินจากบัญชีของเหยื่อไปยังบัญชีของผู้โจมตีโดยฝังคำขอไว้ในรูปภาพที่เก็บไว้ในไซต์ต่างๆภายใต้การควบคุมของผู้โจมตี -

<img src = "http://bankx.com/app?action=transferFunds&amount=14000&destinationAccount=attackersAcct#" 
   width = "0" height = "0" />

Hands ON

Step 1- ให้เราทำการปลอมแปลง CSRF โดยการฝังสคริปต์ Java ลงในรูปภาพ ภาพรวมของปัญหาแสดงอยู่ด้านล่าง

Step 2 - ตอนนี้เราต้องจำลองการถ่ายโอนเป็นภาพ 1x1 และให้เหยื่อคลิกที่เดียวกัน

Step 3 - เมื่อส่งข้อความข้อความจะปรากฏตามไฮไลต์ด้านล่าง

Step 4- ตอนนี้หากเหยื่อคลิก URL ต่อไปนี้การถ่ายโอนจะถูกดำเนินการซึ่งพบได้ว่าขัดขวางการกระทำของผู้ใช้โดยใช้ชุดเรอ เราสามารถดูการถ่ายโอนได้โดยการระบุในข้อความ Get ดังที่แสดงด้านล่าง -

Step 5 - เมื่อคลิกรีเฟรชแล้วเครื่องหมายการจบบทเรียนจะปรากฏขึ้น

กลไกการป้องกัน

  • CSRF สามารถหลีกเลี่ยงได้โดยการสร้างโทเค็นเฉพาะในช่องที่ซ่อนไว้ซึ่งจะถูกส่งไปในเนื้อหาของคำขอ HTTP แทนที่จะเป็น URL ซึ่งมีแนวโน้มที่จะเปิดเผยมากกว่า

  • บังคับให้ผู้ใช้ตรวจสอบสิทธิ์อีกครั้งหรือพิสูจน์ว่าเป็นผู้ใช้เพื่อปกป้อง CSRF ตัวอย่างเช่น CAPTCHA

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

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

ตัวอย่าง

ตัวอย่างต่อไปนี้คือการใช้ส่วนประกอบที่มีช่องโหว่ที่ทราบ -

  • ผู้โจมตีสามารถเรียกใช้บริการเว็บใดก็ได้โดยได้รับอนุญาตเต็มรูปแบบโดยไม่ให้โทเค็นประจำตัว

  • การเรียกใช้รหัสระยะไกลด้วยช่องโหว่การแทรกภาษา Expression ถูกนำมาใช้ผ่าน Spring Framework สำหรับแอปที่ใช้ Java

กลไกการป้องกัน

  • ระบุคอมโพเนนต์ทั้งหมดและเวอร์ชันที่ใช้ในเว็บแอพไม่ จำกัด เฉพาะฐานข้อมูล / เฟรมเวิร์ก

  • ปรับปรุงส่วนประกอบทั้งหมดเช่นฐานข้อมูลสาธารณะรายชื่ออีเมลโครงการ ฯลฯ ให้ทันสมัยอยู่เสมอ

  • เพิ่มตัวป้องกันความปลอดภัยรอบ ๆ ส่วนประกอบที่มีความเสี่ยง

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

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

ตัวอย่าง

ตัวอย่างคลาสสิกบางส่วนของ Unvalidated Redirects and Forward มีดังที่ระบุ -

  • ให้เราบอกโปรแกรมประยุกต์ที่มีหน้า - redirect.jsp ซึ่งใช้พารามิเตอร์redirectrul แฮ็กเกอร์เพิ่ม URL ที่เป็นอันตรายซึ่งเปลี่ยนเส้นทางผู้ใช้ซึ่งทำการฟิชชิง / ติดตั้งมัลแวร์

http://www.mywebapp.com/redirect.jsp?redirectrul=hacker.com
  • เว็บแอปพลิเคชันทั้งหมดใช้เพื่อส่งต่อผู้ใช้ไปยังส่วนต่างๆของไซต์ เพื่อให้บรรลุผลเช่นเดียวกันบางเพจใช้พารามิเตอร์เพื่อระบุตำแหน่งที่ผู้ใช้ควรถูกเปลี่ยนเส้นทางหากการดำเนินการสำเร็จ ผู้โจมตีสร้าง URL ที่ผ่านการตรวจสอบการควบคุมการเข้าถึงของแอปพลิเคชันจากนั้นส่งต่อผู้โจมตีไปยังฟังก์ชันการดูแลระบบซึ่งผู้โจมตีไม่สามารถเข้าถึงได้

http://www.mywebapp.com/checkstatus.jsp?fwd=appadmin.jsp

กลไกการป้องกัน

  • หลีกเลี่ยงการใช้การเปลี่ยนเส้นทางและส่งต่อจะดีกว่า

  • หากหลีกเลี่ยงไม่ได้ก็ควรทำโดยไม่เกี่ยวข้องกับพารามิเตอร์ของผู้ใช้ในการเปลี่ยนเส้นทางปลายทาง

Asynchronous Javascript และ XML (AJAX) เป็นหนึ่งในเทคนิคล่าสุดที่ใช้ในการพัฒนาเว็บแอปพลิเคชันตามลำดับเพื่อมอบประสบการณ์การใช้งานที่หลากหลายแก่ผู้ใช้ เนื่องจากเป็นเทคโนโลยีใหม่จึงมีปัญหาด้านความปลอดภัยจำนวนมากที่ยังไม่เสร็จสมบูรณ์และด้านล่างนี้คือปัญหาด้านความปลอดภัยบางประการใน AJAX

  • พื้นผิวการโจมตีมีมากขึ้นเนื่องจากมีปัจจัยการผลิตที่ปลอดภัยมากขึ้น

  • นอกจากนี้ยังแสดงฟังก์ชันภายในของแอปพลิเคชัน

  • ความล้มเหลวในการปกป้องข้อมูลการตรวจสอบสิทธิ์และเซสชัน

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

ตัวอย่าง

นี่คือตัวอย่างสำหรับ AJAX Security -

ในปี 2549 บริการอีเมล yahoo ที่ติดไวรัสโดยใช้ XSS และ AJAX ซึ่งใช้ประโยชน์จากช่องโหว่ในการจัดการเหตุการณ์ onload ของ Yahoo Mail เมื่อเปิดอีเมลที่ติดไวรัสเวิร์มจะเรียกใช้ JavaScript ส่งสำเนาไปยังผู้ติดต่อ Yahoo ทั้งหมดของผู้ใช้ที่ติดไวรัส

Hands ON

Step 1- เราจำเป็นต้องพยายามเพิ่มรางวัลให้กับชุดรางวัลที่คุณอนุญาตโดยใช้การฉีด XML ด้านล่างนี้คือภาพรวมของสถานการณ์

Step 2- ตรวจสอบให้แน่ใจว่าเราสกัดกั้นทั้งคำขอและการตอบกลับโดยใช้ Burp Suite การตั้งค่าเหมือนกับที่แสดงด้านล่าง

Step 3- ป้อนหมายเลขบัญชีตามที่ระบุในสถานการณ์ เราจะได้รับรายชื่อรางวัลทั้งหมดที่เรามีสิทธิ์ได้รับ เรามีสิทธิ์ได้รับ 3 รางวัลจาก 5 รางวัล

Step 4- ตอนนี้ให้เราคลิก 'ส่ง' และดูสิ่งที่เราได้รับใน XML การตอบกลับ ดังที่แสดงไว้ด้านล่างรางวัลสามรายการที่เรามีสิทธิ์จะถูกส่งให้เราเป็น XML

Step 5 - ตอนนี้ให้เราแก้ไข XML เหล่านั้นและเพิ่มรางวัลอีกสองรางวัลด้วย

Step 6- ตอนนี้รางวัลทั้งหมดจะแสดงให้ผู้ใช้เลือก เลือกรายการที่เราเพิ่มแล้วคลิก "ส่ง"

Step 7 - ข้อความต่อไปนี้ปรากฏขึ้นว่า "* ยินดีด้วยคุณเรียนจบบทเรียนนี้สำเร็จแล้ว"

กลไกการป้องกัน

ฝั่งไคลเอ็นต์ -

  • ใช้ .innerText แทน .innerHtml
  • อย่าใช้ eval
  • อย่าพึ่งพาตรรกะของไคลเอ็นต์เพื่อความปลอดภัย
  • หลีกเลี่ยงการเขียนรหัสซีเรียลไลเซชั่น
  • หลีกเลี่ยงการสร้าง XML แบบไดนามิก
  • อย่าส่งความลับไปยังลูกค้า
  • อย่าทำการเข้ารหัสในรหัสฝั่งไคลเอ็นต์
  • อย่าดำเนินการด้านความปลอดภัยที่ส่งผลกระทบต่อตรรกะในฝั่งไคลเอ็นต์

ฝั่งเซิร์ฟเวอร์ -

  • ใช้การป้องกัน CSRF
  • หลีกเลี่ยงการเขียนรหัสซีเรียลไลเซชั่น
  • บริการสามารถเรียกโดยผู้ใช้โดยตรง
  • หลีกเลี่ยงการสร้าง XML ด้วยมือใช้กรอบ
  • หลีกเลี่ยงการสร้าง JSON ด้วยมือใช้กรอบงานที่มีอยู่

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

Hands ON

Step 1- ไปที่พื้นที่บริการเว็บของ Webgoat และไปที่ WSDL Scanning ตอนนี้เราจำเป็นต้องได้รับรายละเอียดบัตรเครดิตของหมายเลขบัญชีอื่น ๆ ภาพรวมของสถานการณ์มีดังที่กล่าวไว้ด้านล่าง

Step 2 - หากเราเลือกชื่อแรกการเรียกใช้ฟังก์ชัน 'getFirstName' จะทำผ่าน SOAP request xml

Step 3- เมื่อเปิด WSDL เราจะเห็นว่ามีวิธีการดึงข้อมูลบัตรเครดิตเช่นเดียวกับ 'getCreditCard' ตอนนี้ให้เราแก้ไขอินพุตโดยใช้ Burp suite ดังที่แสดงด้านล่าง -

Step 4 - ตอนนี้ให้เราแก้ไขอินพุตโดยใช้ Burp suite ดังที่แสดงด้านล่าง -

Step 5 - เราสามารถรับข้อมูลบัตรเครดิตของผู้ใช้รายอื่นได้

กลไกการป้องกัน

  • เนื่องจากข้อความ SOAP เป็นแบบ XML ข้อมูลรับรองที่ส่งผ่านทั้งหมดจึงต้องถูกแปลงเป็นรูปแบบข้อความ ดังนั้นเราจึงต้องระมัดระวังในการส่งผ่านข้อมูลที่ละเอียดอ่อนซึ่งจะต้องมีการเข้ารหัสเสมอ

  • การปกป้องความสมบูรณ์ของข้อความโดยการนำกลไกเช่นการตรวจสอบมาใช้เพื่อให้แน่ใจว่าแพ็คเก็ตมีความสมบูรณ์

  • การป้องกันการรักษาความลับของข้อความ - การเข้ารหัสแบบอสมมาตรถูกนำไปใช้เพื่อป้องกันคีย์เซสชันแบบสมมาตรซึ่งในการใช้งานจำนวนมากนั้นใช้ได้สำหรับการสื่อสารเพียงครั้งเดียวเท่านั้นและจะถูกยกเลิกในภายหลัง

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

ตัวอย่าง

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

...
   char bufr[BUFSIZE]; 
   gets(bufr);
   ...

Hands ON

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

Step 2 - เราจะเปิดใช้งาน "Unhide hidden form fields" ใน Burp Suite ดังที่แสดงด้านล่าง -

Step 3- ตอนนี้เราส่งข้อมูลในช่องชื่อและหมายเลขห้อง นอกจากนี้เรายังทดลองและฉีดตัวเลขจำนวนมากในช่องหมายเลขห้อง

Step 4- ฟิลด์ที่ซ่อนอยู่จะแสดงดังที่แสดงด้านล่าง เราคลิกยอมรับเงื่อนไข

Step 5 - การโจมตีประสบความสำเร็จเนื่องจากบัฟเฟอร์ล้นมันเริ่มอ่านตำแหน่งหน่วยความจำที่อยู่ติดกันและแสดงต่อผู้ใช้ดังที่แสดงด้านล่าง

Step 6- ตอนนี้ให้เราเข้าสู่ระบบโดยใช้ข้อมูลที่แสดง หลังจากบันทึกข้อความต่อไปนี้จะปรากฏขึ้น -

กลไกการป้องกัน

  • การตรวจสอบโค้ด
  • การฝึกอบรมนักพัฒนา
  • เครื่องมือคอมไพเลอร์
  • การพัฒนาฟังก์ชัน Safe
  • การสแกนเป็นระยะ

การโจมตี Denial of Service (DoS) เป็นความพยายามของแฮกเกอร์เพื่อทำให้ทรัพยากรเครือข่ายไม่สามารถใช้งานได้ โดยปกติจะขัดขวางโฮสต์ชั่วคราวหรือไม่มีกำหนดซึ่งเชื่อมต่อกับอินเทอร์เน็ต โดยทั่วไปการโจมตีเหล่านี้จะกำหนดเป้าหมายบริการที่โฮสต์บนเว็บเซิร์ฟเวอร์ที่สำคัญเช่นธนาคารเกตเวย์การชำระเงินด้วยบัตรเครดิต

อาการของ DoS

  • ประสิทธิภาพของเครือข่ายช้าผิดปกติ
  • ไม่มีเว็บไซต์ใดเว็บไซต์หนึ่ง
  • ไม่สามารถเข้าถึงเว็บไซต์ใด ๆ
  • จำนวนอีเมลขยะที่ได้รับเพิ่มขึ้นอย่างมาก
  • การปฏิเสธการเข้าถึงเว็บหรือบริการอินเทอร์เน็ตในระยะยาว
  • ความไม่พร้อมใช้งานของเว็บไซต์ใดเว็บไซต์หนึ่ง

Hands ON

Step 1- เปิด WebGoat และไปที่ส่วน 'ปฏิเสธการให้บริการ' ภาพรวมของสถานการณ์ได้รับด้านล่าง เราจำเป็นต้องล็อกอินหลายครั้งโดยการละเมิดขนาดเธรดพูล DB สูงสุด

Step 2- ก่อนอื่นเราต้องได้รับรายชื่อการเข้าสู่ระบบที่ถูกต้อง เราใช้ SQL Injection ในกรณีนี้

Step 3 - หากความพยายามสำเร็จจะแสดงข้อมูลรับรองที่ถูกต้องทั้งหมดให้กับผู้ใช้

Step 4- ตอนนี้เข้าสู่ระบบกับผู้ใช้แต่ละคนในเซสชันที่แตกต่างกันอย่างน้อย 3 ครั้งเพื่อให้การโจมตี DoS ประสบความสำเร็จ อย่างที่เราทราบกันดีว่าการเชื่อมต่อ DB สามารถจัดการเธรดได้เพียงสองเธรดโดยการใช้การล็อกอินทั้งหมดมันจะสร้างเธรดสามเธรดซึ่งทำให้การโจมตีประสบความสำเร็จ

กลไกการป้องกัน

  • ดำเนินการตรวจสอบอินพุตอย่างละเอียด

  • หลีกเลี่ยงการใช้งาน CPU สูง

  • แยกดิสก์ข้อมูลออกจากดิสก์ระบบจะดีกว่า

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

ตัวอย่าง

ตัวอย่างคลาสสิกบางส่วน ได้แก่ -

  • อัปโหลดไฟล์. jsp ไปยังแผนผังเว็บ
  • อัปโหลด. gif เพื่อปรับขนาด
  • อัปโหลดไฟล์ขนาดใหญ่
  • อัปโหลดไฟล์ที่มีแท็ก
  • อัปโหลดไฟล์. exe ไปยังแผนผังเว็บ

Hands ON

Step 1- เปิด WebGoat และไปที่ส่วนการเรียกใช้ไฟล์ที่เป็นอันตราย ภาพรวมของสถานการณ์แสดงไว้ด้านล่าง -

Step 2 - เพื่อให้บทเรียนนี้สมบูรณ์เราจำเป็นต้องอัปโหลด guest.txt ในตำแหน่งดังกล่าวข้างต้น

Step 3- ให้เราสร้างไฟล์ jsp เพื่อให้ไฟล์ guest.txt ถูกสร้างขึ้นจากการเรียกใช้งาน jsp การตั้งชื่อของ jsp ไม่มีบทบาทในบริบทนี้เนื่องจากเรากำลังเรียกใช้เนื้อหาของไฟล์ jsp

<HTML> 
   <% java.io.File file = new 
      java.io.File("C:\\Users\\username$\\.extract\\webapps\\WebGoat\\mfe_target\\guest.txt"); 
      file.createNewFile(); %> 
</HTML>

Step 4- ตอนนี้อัปโหลดไฟล์ jsp และคัดลอกตำแหน่งลิงค์ที่เหมือนกันหลังจากอัปโหลด การอัปโหลดคาดว่าจะเป็นรูปภาพ แต่เรากำลังอัปโหลด jsp

Step 5 - เมื่อไปที่ไฟล์ jsp จะไม่มีข้อความใด ๆ ถึงผู้ใช้

Step 6 - ตอนนี้รีเฟรชเซสชันที่คุณอัปโหลดไฟล์ jsp แล้วคุณจะได้รับข้อความว่า "* ขอแสดงความยินดีคุณทำบทเรียนสำเร็จแล้ว"

กลไกการป้องกัน

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

มีเครื่องมือมากมายสำหรับทำการทดสอบความปลอดภัยของแอปพลิเคชัน มีเครื่องมือเพียงไม่กี่เครื่องมือที่สามารถทำการทดสอบความปลอดภัยแบบ end-to-end ได้ในขณะที่บางประเภทมีไว้เพื่อตรวจหาข้อบกพร่องบางประเภทในระบบโดยเฉพาะ

เครื่องมือโอเพนซอร์ส

เครื่องมือทดสอบความปลอดภัยโอเพนซอร์สบางตัวมีดังที่ระบุ

ส. ชื่อเครื่องมือ
1

Zed Attack Proxy

มีเครื่องสแกนอัตโนมัติและเครื่องมืออื่น ๆ สำหรับตรวจจับข้อบกพร่องด้านความปลอดภัย

https://www.owasp.org

2

OWASP WebScarab

พัฒนาใน Java สำหรับการวิเคราะห์คำขอ Http และ Https

https://www.owasp.org/index.php

3

OWASP Mantra

รองรับกรอบการทดสอบความปลอดภัยหลายภาษา

https://www.owasp.org/index.php/OWASP_Mantra_-_Security_Framework

4

Burp Proxy

เครื่องมือสำหรับสกัดกั้นและลอกเลียนการรับส่งข้อมูลและทำงานร่วมกับใบรับรอง SSL ที่กำหนดเอง

https://www.portswigger.net/Burp/

5

Firefox Tamper Data

ใช้ tamperdata เพื่อดูและแก้ไขส่วนหัว HTTP / HTTPS และโพสต์พารามิเตอร์

https://addons.mozilla.org/en-US

6

Firefox Web Developer Tools

ส่วนขยาย Web Developer จะเพิ่มเครื่องมือสำหรับนักพัฒนาเว็บต่างๆให้กับเบราว์เซอร์

https://addons.mozilla.org/en-US/firefox

7

Cookie Editor

ช่วยให้ผู้ใช้สามารถเพิ่มลบแก้ไขค้นหาป้องกันและบล็อกคุกกี้

https://chrome.google.com/webstore

ชุดเครื่องมือเฉพาะ

เครื่องมือต่อไปนี้สามารถช่วยให้เราระบุช่องโหว่บางประเภทในระบบได้ -

ส. ลิงค์
1

DOMinator Pro − Testing for DOM XSS

https://dominator.mindedsecurity.com/

2

OWASP SQLiX − SQL Injection

https://www.owasp.org/index.php

3

Sqlninja − SQL Injection

http://sqlninja.sourceforge.net/

4

SQLInjector − SQL Injection

https://sourceforge.net/projects/safe3si/

5

sqlpowerinjector − SQL Injection

http://www.sqlpowerinjector.com/

6

SSL Digger − Testing SSL

https://www.mcafee.com/us/downloads/free-tools

7

THC-Hydra − Brute Force Password

https://www.thc.org/thc-hydra/

8

Brutus − Brute Force Password

http://www.hoobie.net/brutus/

9

Ncat − Brute Force Password

https://nmap.org/ncat/

10

OllyDbg − Testing Buffer Overflow

http://www.ollydbg.de/

11

Spike − Testing Buffer Overflow

https://www.immunitysec.com/downloads/SPIKE2.9.tgz

12

Metasploit − Testing Buffer Overflow

https://www.metasploit.com/

เครื่องมือทดสอบกล่องดำเชิงพาณิชย์

นี่คือเครื่องมือทดสอบกล่องดำเชิงพาณิชย์บางส่วนที่ช่วยให้เราพบปัญหาด้านความปลอดภัยในแอปพลิเคชันที่เราพัฒนา

ส. เลขที่ เครื่องมือ
1

NGSSQuirreL

https://www.nccgroup.com/en/our-services

2

IBM AppScan

https://www-01.ibm.com/software/awdtools/appscan/

3

Acunetix Web Vulnerability Scanner

https://www.acunetix.com/

4

NTOSpider

https://www.ntobjectives.com/products/ntospider.php

5

SOAP UI

https://www.soapui.org/Security/getting-started.html

6

Netsparker

https://www.mavitunasecurity.com/netsparker/

7

HP WebInspect

http://www.hpenterprisesecurity.com/products

เครื่องวิเคราะห์ซอร์สโค้ดฟรี

ส. เลขที่ เครื่องมือ
1

OWASP Orizon

https://www.owasp.org/index.php

2

OWASP O2

https://www.owasp.org/index.php/OWASP_O2_Platform

3

SearchDiggity

https://www.bishopfox.com/resources/tools

4

FXCOP

https://www.owasp.org/index.php/FxCop

5

Splint

http://splint.org/

6

Boon

https://www.cs.berkeley.edu/~daw/boon/

7

W3af

http://w3af.org/

8

FlawFinder

https://www.dwheeler.com/flawfinder/

9

FindBugs

http://findbugs.sourceforge.net/

เครื่องวิเคราะห์ซอร์สโค้ดเชิงพาณิชย์

เครื่องวิเคราะห์เหล่านี้จะตรวจสอบตรวจจับและรายงานจุดอ่อนในซอร์สโค้ดซึ่งมีแนวโน้มที่จะมีช่องโหว่ -

ส. เลขที่ เครื่องมือ
1

Parasoft C/C++ test

https://www.parasoft.com/cpptest/

2

HP Fortify

http://www.hpenterprisesecurity.com/products

3

Appscan

http://www-01.ibm.com/software/rational/products

4

Veracode

https://www.veracode.com

5

Armorize CodeSecure

http://www.armorize.com/codesecure/

6

GrammaTech

https://www.grammatech.com/