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

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

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

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

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

• 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/