อย่าใส่รหัสผ่านแบบฮาร์ดโค้ดลงในรหัสของคุณ สิ่งนี้ถูกนำมาใช้เมื่อไม่นานมานี้ในข้อผิดพลาดในการเขียนโปรแกรมที่อันตรายที่สุด 25 อันดับแรก :
การเข้ารหัสบัญชีลับและรหัสผ่านลงในซอฟต์แวร์ของคุณอย่างหนักนั้นสะดวกมากสำหรับวิศวกรย้อนกลับที่มีทักษะ หากรหัสผ่านเหมือนกันในซอฟต์แวร์ทั้งหมดของคุณลูกค้าทุกคนจะมีช่องโหว่เมื่อรู้รหัสผ่านนั้นอย่างหลีกเลี่ยงไม่ได้ และเนื่องจากเป็นฮาร์ดโค้ดจึงเป็นความเจ็บปวดอย่างมากในการแก้ไข
คุณควรจัดเก็บข้อมูลการกำหนดค่ารวมถึงรหัสผ่านไว้ในไฟล์แยกต่างหากที่แอปพลิเคชันอ่านเมื่อเริ่มทำงาน นั่นเป็นวิธีเดียวที่แท้จริงในการป้องกันไม่ให้รหัสผ่านรั่วไหลอันเป็นผลมาจากการแยกคอมไพล์ (ห้ามคอมไพล์ลงในไบนารีเพื่อเริ่มต้นด้วย)
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับความผิดพลาดที่พบบ่อยนี้คุณสามารถอ่านบทความ CWE-259 บทความนี้มีคำจำกัดความตัวอย่างและข้อมูลอื่น ๆ เกี่ยวกับปัญหาอย่างละเอียดมากขึ้น
ใน Java วิธีที่ง่ายที่สุดวิธีหนึ่งคือการใช้คลาส Preferences ออกแบบมาเพื่อจัดเก็บการตั้งค่าโปรแกรมทุกประเภทซึ่งบางส่วนอาจรวมถึงชื่อผู้ใช้และรหัสผ่าน
import java.util.prefs.Preferences;
public class DemoApplication {
Preferences preferences =
Preferences.userNodeForPackage(DemoApplication.class);
public void setCredentials(String username, String password) {
preferences.put("db_username", username);
preferences.put("db_password", password);
}
public String getUsername() {
return preferences.get("db_username", null);
}
public String getPassword() {
return preferences.get("db_password", null);
}
}
ในรหัสด้านบนคุณสามารถเรียกใช้setCredentialsเมธอดได้หลังจากแสดงกล่องโต้ตอบถามหาชื่อผู้ใช้และรหัสผ่าน เมื่อคุณต้องการเชื่อมต่อกับฐานข้อมูลคุณสามารถใช้getUsernameและgetPasswordวิธีการเพื่อดึงค่าที่เก็บไว้ ข้อมูลรับรองการเข้าสู่ระบบจะไม่ถูกฮาร์ดโค้ดลงในไบนารีของคุณดังนั้นการแยกคอมไพล์จะไม่ก่อให้เกิดความเสี่ยงด้านความปลอดภัย
หมายเหตุสำคัญ:ไฟล์การกำหนดลักษณะเป็นเพียงไฟล์ XML ข้อความธรรมดา ตรวจสอบให้แน่ใจว่าคุณดำเนินการตามขั้นตอนที่เหมาะสมเพื่อป้องกันไม่ให้ผู้ใช้ที่ไม่ได้รับอนุญาตดูไฟล์ดิบ (สิทธิ์ UNIX, สิทธิ์ของ Windows, และอื่น ๆ ) ใน Linux อย่างน้อยก็ไม่ใช่ปัญหาเพราะการโทรPreferences.userNodeForPackageจะสร้างไฟล์ XML ในโฮมไดเร็กทอรีของผู้ใช้ปัจจุบันซึ่งผู้ใช้รายอื่นไม่สามารถอ่านได้ ใน Windows สถานการณ์อาจแตกต่างออกไป
หมายเหตุสำคัญเพิ่มเติม:มีการอภิปรายมากมายในความคิดเห็นของคำตอบนี้และอื่น ๆ เกี่ยวกับสถาปัตยกรรมที่ถูกต้องสำหรับสถานการณ์นี้ คำถามเดิมไม่ได้กล่าวถึงบริบทที่ใช้แอปพลิเคชันจริงๆดังนั้นฉันจะพูดถึงสองสถานการณ์ที่ฉันคิดได้ ประการแรกคือกรณีที่บุคคลที่ใช้โปรแกรมรู้อยู่แล้ว (และได้รับอนุญาตให้รู้) ข้อมูลรับรองฐานข้อมูล ประการที่สองคือกรณีที่คุณซึ่งเป็นผู้พัฒนาพยายามเก็บข้อมูลรับรองฐานข้อมูลเป็นความลับจากบุคคลที่ใช้โปรแกรม
กรณีแรก: ผู้ใช้ได้รับอนุญาตให้ทราบข้อมูลรับรองการเข้าสู่ระบบฐานข้อมูล
ในกรณีนี้วิธีแก้ปัญหาที่ฉันกล่าวถึงข้างต้นจะได้ผล PreferenceคลาสJava จะจัดเก็บชื่อผู้ใช้และรหัสผ่านเป็นข้อความธรรมดา แต่ไฟล์การกำหนดค่าตามความชอบจะสามารถอ่านได้โดยผู้ใช้ที่ได้รับอนุญาตเท่านั้น ผู้ใช้สามารถเปิดไฟล์ XML การกำหนดค่าตามความชอบและอ่านข้อมูลรับรองการเข้าสู่ระบบได้ แต่นั่นไม่ใช่ความเสี่ยงด้านความปลอดภัยเนื่องจากผู้ใช้ทราบข้อมูลรับรองที่จะเริ่มต้นด้วย
กรณีที่สอง: พยายามซ่อนข้อมูลรับรองการเข้าสู่ระบบจากผู้ใช้
นี่เป็นกรณีที่ซับซ้อนมากขึ้น: ผู้ใช้ไม่ควรทราบข้อมูลรับรองการเข้าสู่ระบบ แต่ยังคงต้องการเข้าถึงฐานข้อมูล ในกรณีนี้ผู้ใช้ที่เรียกใช้แอปพลิเคชันจะมีสิทธิ์เข้าถึงฐานข้อมูลโดยตรงซึ่งหมายความว่าโปรแกรมจำเป็นต้องทราบข้อมูลรับรองการเข้าสู่ระบบล่วงหน้า วิธีแก้ปัญหาที่ฉันกล่าวถึงข้างต้นไม่เหมาะสมสำหรับกรณีนี้ คุณสามารถจัดเก็บข้อมูลรับรองการเข้าสู่ระบบฐานข้อมูลในไฟล์การตั้งค่า แต่ผู้ใช้จะสามารถอ่านไฟล์นั้นได้เนื่องจากพวกเขาจะเป็นเจ้าของ ในความเป็นจริงไม่มีวิธีใดที่ดีในการใช้กรณีนี้อย่างปลอดภัย
กรณีที่ถูกต้อง: การใช้สถาปัตยกรรมหลายชั้น
วิธีที่ถูกต้องในการดำเนินการคือต้องมีชั้นกลางระหว่างเซิร์ฟเวอร์ฐานข้อมูลและแอปพลิเคชันไคลเอนต์ของคุณซึ่งจะตรวจสอบผู้ใช้แต่ละรายและอนุญาตให้ดำเนินการเฉพาะบางกลุ่ม ผู้ใช้แต่ละคนจะมีข้อมูลรับรองการเข้าสู่ระบบของตนเอง แต่ไม่ใช่สำหรับเซิร์ฟเวอร์ฐานข้อมูล ข้อมูลรับรองจะอนุญาตให้เข้าถึงเลเยอร์กลาง (ระดับตรรกะทางธุรกิจ) และจะแตกต่างกันสำหรับผู้ใช้แต่ละราย
ผู้ใช้ทุกคนจะมีชื่อผู้ใช้และรหัสผ่านของตนเองซึ่งสามารถเก็บไว้ในไฟล์ค่ากำหนดโดยไม่มีความเสี่ยงด้านความปลอดภัย สิ่งนี้เรียกว่าสถาปัตยกรรมสามชั้น (ระดับที่เป็นเซิร์ฟเวอร์ฐานข้อมูลเซิร์ฟเวอร์ตรรกะทางธุรกิจและแอปพลิเคชันไคลเอนต์) มันซับซ้อนกว่า แต่จริงๆแล้วเป็นวิธีที่ปลอดภัยที่สุดในการทำสิ่งนี้
ลำดับพื้นฐานของการดำเนินการคือ:
- ลูกค้าตรวจสอบสิทธิ์ด้วยระดับตรรกะทางธุรกิจโดยใช้ชื่อผู้ใช้ / รหัสผ่านส่วนตัวของผู้ใช้ ชื่อผู้ใช้และรหัสผ่านเป็นที่รู้จักของผู้ใช้และไม่เกี่ยวข้องกับข้อมูลรับรองการเข้าสู่ระบบฐานข้อมูล แต่อย่างใด
- หากการรับรองความถูกต้องสำเร็จไคลเอ็นต์จะร้องขอไปยังระดับตรรกะทางธุรกิจเพื่อขอข้อมูลบางอย่างจากฐานข้อมูล ตัวอย่างเช่นสินค้าคงคลังของผลิตภัณฑ์ โปรดทราบว่าคำขอของลูกค้าไม่ใช่แบบสอบถาม SQL เป็นการเรียกโพรซีเดอร์ระยะไกลเช่น
getInventoryList.
- ระดับตรรกะทางธุรกิจเชื่อมต่อกับฐานข้อมูลและดึงข้อมูลที่ร้องขอ ระดับตรรกะทางธุรกิจรับผิดชอบในการสร้างแบบสอบถาม SQL ที่ปลอดภัยตามคำขอของผู้ใช้ พารามิเตอร์ใด ๆ ในแบบสอบถาม SQL ควรได้รับการฆ่าเชื้อเพื่อป้องกันการโจมตีด้วยการฉีด SQL
- ระดับตรรกะทางธุรกิจจะส่งรายการสินค้าคงคลังกลับไปยังแอปพลิเคชันไคลเอนต์
- ไคลเอนต์แสดงรายการสินค้าคงคลังให้กับผู้ใช้
ทราบว่าในกระบวนการทั้งหมดโปรแกรมไคลเอนต์ไม่เคยเชื่อมต่อโดยตรงกับฐานข้อมูล ระดับตรรกะทางธุรกิจได้รับคำร้องขอจากผู้ใช้ที่ได้รับการพิสูจน์ตัวตนประมวลผลคำขอของไคลเอ็นต์สำหรับรายการสินค้าคงคลังจากนั้นจึงดำเนินการสืบค้น SQL เท่านั้น