จะทำให้ผู้ดูแลระบบมั่นใจได้อย่างไรว่า Java ON A SERVER ไม่ปลอดภัยต่อผู้ใช้งาน

แอพพลิเคชั่น

เรามีแอปพลิเคชั่น Java ขนาดเล็กซึ่งใช้เส้นทาง Camel บางเส้นทางเพื่อรับไฟล์ที่อัปโหลดจากเว็บเซิร์ฟเวอร์ประมวลผลและส่งอีเมลพร้อมผลลัพธ์

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

ความกลัว

ฉันเป็นวิศวกรแอปพลิเคชัน Java ด้วยตัวเองฉันเขียนรหัส JEE เพื่อหาเลี้ยงชีพจัดการธุรกรรม B2B ที่มีมูลค่านับหมื่นยูโรต่อสัปดาห์ แต่ฉันมีปัญหาในการค้นหาแหล่งข้อมูลที่น่าเชื่อถือซึ่งหักล้างตำนานที่ java ไม่ปลอดภัยต่อ se

อาร์กิวเมนต์หลักสองข้อของผู้ดูแลระบบในการติดตั้ง JRE:

1. แอปพลิเคชัน Java กิน RAM ของฉันหมด
2. Java เต็มไปด้วยช่องโหว่

ความจริง?

เมื่อพูดถึงจาวาแอพพลิเคชั่นที่กิน RAM ดี ... ฉันว่าเราต้องตั้งค่าที่เหมาะสมสำหรับ Xmx เสร็จสิ้น

ขณะนี้มีแหล่งข้อมูลจำนวนมากพูดถึงช่องโหว่จำนวนมากของ Java แหล่งข้อมูลเหล่านี้ส่วนใหญ่มุ่งที่ผู้ใช้ปลายทางที่ใช้ระบบปฏิบัติการบางอย่างจาก บริษัท ใน Redmond / USA AFAIK อาจเป็นจริงสำหรับ Java Browser Plugin เวอร์ชันที่ไม่ได้เปรียบเทียบซึ่งกำหนดค่าให้เรียกใช้งานแอพเพล็ตทั้งหมดโดยอัตโนมัติว่ามีโอกาสที่ค่อนข้างใหญ่ที่จะตกเป็นเหยื่อของไดรฟ์ที่ติดไวรัส เนื่องจากมีความเสี่ยงที่จะติดโรคติดต่อทางเพศสัมพันธ์เมื่อมีเพศสัมพันธ์ที่ไม่มีการป้องกันด้วย eveyone บนรถไฟขณะเดินทางไปทำงาน

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

หรือว่าฉันขาดอะไรบางอย่างที่นี่?

[แก้ไข 2014-08-28] ชี้แจง: ฉันกังวลเฉพาะเกี่ยวกับ Java บนเซิร์ฟเวอร์ ฉันไม่สนใจปัญหาเกี่ยวกับปลั๊กอิน Java และ / หรือซอฟต์แวร์เฉพาะที่พัฒนาใน java

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

ประการแรกมีเร็กคอร์ดที่น่ากลัวที่ JRE ใช้ในการมีข้อบกพร่องด้านความปลอดภัย เป็นการยากที่จะชี้ให้เห็นสิ่งที่เฉพาะเจาะจงและนี่คือส่วนที่น่ากลัว - ข้อผิดพลาดเป็นช่องโหว่ที่ไม่ระบุรายละเอียดด้วยพาหะที่ไม่ระบุรายละเอียด

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

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

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

โดยเฉพาะอย่างยิ่งหากมีรีโมตใน JRE ที่อนุญาตให้ผู้โจมตีได้รับ RCE และอีกอันใน PHP ที่ทำเช่นเดียวกันและอีกอันใน Ruby ที่ทำเหมือนเดิมอีกครั้งคุณต้องแก้ไขทั้งสาม ทั้งสามดูเหมือนว่าค่อนข้างเป็นไปตามสิ่งเหล่านี้ไปและผู้โจมตีจะเลือกสิ่งที่สะดวกที่สุดแล้วเป็นเจ้าของเซิร์ฟเวอร์ทั้งหมด นั่นเป็นเหตุผลที่เราควรใช้ VMs เพื่อแยกซอฟต์แวร์โดยเฉพาะอย่างยิ่งซอฟต์แวร์ buggy เช่นกรอบภาษาที่ได้รับการจัดการและโดยเฉพาะอย่างยิ่งที่รวมชุดข้อมูลความปลอดภัยเพียงสี่ครั้งต่อปีและเป็นกรรมสิทธิ์ของผู้ขายที่ยืนยันหลักฐานทั้งหมดว่าเป็นส่วนสำคัญ ความปลอดภัย

หากต้องการอัปเดตนี่คือ CVE บางส่วนที่ฉันคัดสรรมาจากการค้นหา CVE ที่เชื่อมโยงของ ChrisS โดยการสาธิต

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5884
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5910
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5456
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3007
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2454
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2447
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1557

และสิ่งที่ฉันชอบตั้งแต่ฉันอยู่ที่นั่น:

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1488

นั่นเป็นเพียงตัวอย่างเล็ก ๆ โดยวิธีการ

แอปพลิเคชัน Java กิน RAM ของฉันหมด

ทางเลือกในการใช้ RAM คือการสิ้นเปลืองแรม คุณไม่สามารถบันทึกได้ในภายหลัง

Java เต็มไปด้วยช่องโหว่

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

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

เรียกเก็บเงินรหัสค่าใช้จ่ายของทีมผู้ดูแลระบบของคุณอย่างชัดเจน

อธิบายว่าภาษาอื่น ๆ (หรือเครื่องเสมือน) สามารถแสดงผลที่ไม่ปลอดภัยโดยรหัสที่ปรับใช้กับพวกเขาเช่นเดียวกับ Java หากเขาคิดว่าแพลตฟอร์มอื่น ๆ นั้นมีความปลอดภัย (หรือปลอดภัยกว่า Java) โดยที่ไม่มีการรักษาความปลอดภัยที่ถูกต้องแสดงว่าเขานั้นหลงผิด

บริษัท ของคุณลงทุนอย่างชัดเจนในการว่าจ้างนักพัฒนา Java ทำไมระบบดูแลปฏิเสธที่จะสนับสนุนเทคโนโลยีที่ บริษัท ตัดสินใจใช้

ฉันจะพลิกคำถามและถามเขาว่ามีตัวเลือกอื่นอย่างไรและพวกเขาปลอดภัยอย่างไรกว่า Server JRE ล่าสุดที่มีให้ในแง่ที่เฉพาะเจาะจงมาก ในเวลานั้นพยายามที่จะแสดงให้คุณเข้าใจเทคโนโลยีของคุณพื้นผิวการโจมตีที่เป็นไปได้และคุณได้พยายามลดให้น้อยที่สุด (เช่นเฟรมเวิร์กที่ไม่จำเป็นรหัสของบุคคลที่สาม ฯลฯ ) ตรวจสอบรหัสของคุณแล้วมองหาช่องโหว่ที่เผยแพร่สำหรับเฟรมเวิร์กที่คุณวางใจในช่วงสิบปีที่ผ่านมาเปรียบเทียบกับภาษา / กรอบงานอื่น ๆ (ตรวจสอบให้แน่ใจว่าได้รวมตลาดแชร์ด้วยเช่นกัน

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