ทำไมเราต้องการความปลอดภัยระดับวิธี?

ในโลกแห่งความจริงทำไมเราต้องใช้การรักษาความปลอดภัยระดับวิธีการ?

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

ดังนั้นการเข้าถึงวิธีที่เข้ามาในรูปภาพโดยตรงที่นี่?

แก้ไข: ฉันถามคำถามนี้เพราะฉันกำลังทดสอบความปลอดภัยของฤดูใบไม้ผลิและฉันเห็นผู้ใช้อนุญาตให้เข้าถึงวิธีการ

สิ่งที่ต้องการ :

 @ROLE_ADMIN
public void update() {
      //update
}

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

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

ในแง่ของการควบคุมที่ละเอียดยิ่งขึ้นสำหรับการเข้าถึงตามบทบาทให้พิจารณาสิ่งนี้:

• สะดวกในการจัดกลุ่มการกระทำทั้งหมดรอบ ๆ ทรัพยากรเข้าด้วยกัน เช่นการสร้าง / อ่าน / อัปเดต / ลบ (CRUD) ของคุณสำหรับบทความบัญชี ฯลฯ สิ่งนี้ทำให้ REST สไตล์ APIs ง่ายต่อการเขียนและบำรุงรักษา
• ระบบจำนวนมากมีหนังสือรับรอง / บทบาทที่แตกต่างกันที่จำเป็นสำหรับการสร้าง / อัปเดต / ลบการดำเนินการมากกว่าที่พวกเขาทำเพื่ออ่านการกระทำ
• หากการกระทำของบัญชีผู้ใช้ทั้งหมดอยู่ในคอนโทรลเลอร์เดียวคุณต้องการอนุญาตให้ทุกคนเข้าสู่ระบบ แต่มีเพียงบางคนเท่านั้นที่จะสร้างบัญชีใหม่หรือกำหนดบทบาท

ชอบหรือไม่เมื่อ Ruby on Rails ชนคลื่นเมื่อไม่กี่ปีที่แล้วเฟรมเวิร์ค MVC เกือบทุกตัวคัดลอกวิธีการออกแบบพื้นฐาน มันเคยเป็นที่การกระทำที่แยกชั้นเรียน แต่ตรรกะการกระทำมีแนวโน้มที่จะมีขนาดเล็กและมุ่งเน้นเพื่อให้ค่าใช้จ่ายในชั้นเรียนเต็มเป็น overkill การแมปเมธอดบนคอนโทรลเลอร์กับแอ็คชันสำหรับเพจทำให้ใช้งานได้จริง เพิ่งรู้ว่าหลายคนต้องการการควบคุมอย่างละเอียดว่าบทบาทใดสามารถปฏิบัติหน้าที่ใดได้บ้าง

การรักษาความปลอดภัยระดับเมธอดมีประโยชน์ด้วยเหตุผลหลักสองประการ:

• เป็นอีกชั้นหนึ่งของความปลอดภัย (นอกเหนือจากเลเยอร์อื่น ๆ )

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

Mike Wiesner เตือนในงานนำเสนอ SpringSource นี้Introduction to Spring Security 3 / 3.1นำตัวอย่างที่ Tomcat และคอนเทนเนอร์ Servlets อื่น ๆ อีกมากมายมีข้อผิดพลาดที่ไม่สามารถจดจำ "../" เมื่อเข้ารหัสในยูนิโค้ดในลักษณะที่ การทดสอบอย่างง่ายจะล้มเหลวใน Java แต่จะแปลไปยังไดเรกทอรีด้านบนในระบบไฟล์

ความปลอดภัยเป็นเรื่องยากระดับความปลอดภัยหลายระดับจะเพิ่มโอกาสในการปิดกั้นความพยายามในการหลบเลี่ยง เนื่องจากการรักษาความปลอดภัยระดับวิธีการถูกเข้ารหัสโดยตรงภายในชั้นเรียนหลังจากการเพิ่ม AOP เมื่อคุณเรียกใช้วิธีการคุณจะต้องเรียกการตรวจสอบความปลอดภัยก่อนเสมอ

ฉันคิดว่าคุณกำลังพูดถึงวิธีสาธารณะสาธารณะและการป้องกันที่นี่?

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

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

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