ในช่วงสองสามรุ่นล่าสุดของ AppScan คุณอาจสังเกตเห็นว่าเราได้ประกาศรองรับการสแกนซอร์สโค้ดสำหรับ Java, .Net และ C/C++ สำหรับความสามารถในการวิเคราะห์แบบคงที่ของเรา มีความแตกต่างที่สำคัญระหว่างสองวิธีซึ่งทำให้แต่ละวิธีมีความเหมาะสมสำหรับกรณีการใช้งานที่แตกต่างกัน

Bytecode/Compiled & Source Code ในระดับสูง

ในอดีต AppScan ได้ทำการวิเคราะห์โฟลว์ข้อมูลสำหรับ Java, .Net และ C/C++ . การวิเคราะห์จะสร้างแผนผังของข้อมูลที่ไหลผ่านแอปพลิเคชัน เอ็นจิ้นสร้างแผนที่นี้โดยการอ่าน Java bytecode, .NET MSIL และโดยการจำลองการคอมไพล์ใน C\C++ จากนั้นแผนที่จะถูกวิเคราะห์เพื่อค้นหาทางเข้า (แหล่งที่มา) และทางออก (อ่างล้างมือ) ชี้ออกจากการควบคุมของรหัส การวิเคราะห์จะสร้างการค้นหาแหล่งข้อมูลที่พบว่ามีทางเดินไปยังอ่างล้างจานและไม่พบรูทีนที่ทำความสะอาดข้อมูล

ความแม่นยำ

ไบต์โค้ด/การสแกนที่คอมไพล์แล้ว 

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

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

การสแกนซอร์สโค้ด

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

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

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

กรองผลลัพธ์ 

ไบต์โค้ด/การสแกนที่คอมไพล์แล้ว 

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

ยิ่งไปกว่านั้น ผลลัพธ์ที่คุณได้รับจะมี DataFlow ที่แสดงส่วนต่างๆ ของแอปพลิเคชันที่สัมผัสกับข้อมูล เมื่อคุณตรวจสอบผลลัพธ์และระบุสารฆ่าเชื้อหรือเครื่องมือตรวจสอบ คุณสามารถกลับมาและบอกว่าเส้นทางเฉพาะนี้ไม่เสี่ยงต่อการถูกโจมตี เมื่อคุณดูผลลัพธ์ คุณสามารถสร้างตัวกรองขั้นสูงได้ เนื่องจากคุณสามารถวิเคราะห์ข้อมูล ติดตามจาก Source ไปยัง Sink และขั้นตอนที่ดำเนินการได้ พวกเขาสามารถซ่อนหรือลบปัญหาเฉพาะตามคุณสมบัติของการติดตามนี้ นอกจากนี้ยังช่วยให้คุณสามารถจัดกลุ่มสิ่งต่างๆ ตามแหล่งที่มา ซิงก์ หรือ API ต่างๆ ในทางกลับกัน วิธีนี้จะช่วยให้คุณวิเคราะห์ได้อย่างรวดเร็วว่าแอปพลิเคชันของคุณเสี่ยงต่อการโจมตีแบบเฉพาะเจาะจงหรือไม่

การสแกนซอร์สโค้ด

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

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

กรณีการใช้งาน

ไบต์โค้ด/การสแกนที่คอมไพล์แล้ว 

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

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

DataFlow ยังแนะนำสำหรับแอปพลิเคชันที่สำคัญเพื่อค้นหาช่องโหว่ให้มากที่สุดอย่างแม่นยำโดยเร็วที่สุด

ที่ดีสำหรับ:

• สแกนข้ามคืนในโครงการขนาดใหญ่
• ไปป์ไลน์อัตโนมัติสำหรับไมโครเซอร์วิส
• การตรวจสอบรหัสด้วยตนเอง

การสแกนซอร์สโค้ด

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

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

ที่ดีสำหรับ:

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

จุดร่วม

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

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