คู่มือที่ครอบคลุมเกี่ยวกับแนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยของ Rails

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

ก่อนที่เราจะเจาะลึกรายละเอียดด้านความปลอดภัยของ Ruby on Rails เรามาใช้เวลาสักครู่เพื่อไตร่ตรองช่วงเวลาดีๆ ก่อน

... และตอนนี้กลับมาสู่โลกแห่งความเป็นจริงแล้ว

น่าเสียดายที่คุณต้องกังวลเกี่ยวกับภัยคุกคามด้านความปลอดภัยด้วยซ้ำ น่าเสียดายที่มีคนที่ตื่นขึ้นมาทุกเช้าและพยายามทำลายสิ่งที่คุณกำลังสร้าง

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

ลูกค้าของคุณไม่สามารถทำให้รหัสของคุณปลอดภัยในนามของคุณได้ ผู้จัดการของคุณไม่สามารถทำเพื่อคุณได้ มันทั้งหมดอยู่ที่คุณ ดังนั้นคุณควรรู้ว่าคุณกำลังทำอะไรอยู่

เหตุใดคุณจึงควรใส่ใจเรื่องความปลอดภัยของ Rails

• คุณพยายามปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยแต่ไม่เข้าใจจริงๆ หรือไม่
• คุณไม่ชัดเจนเกี่ยวกับวิธีการทำงานของการโจมตี XSRF, MITM และ XSR
• คุณคิดว่าเนื่องจากแอปของคุณมีขนาดเล็กหรือภายใน จึงไม่มีความเสี่ยง

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

คุณคิดว่าใบสมัครของคุณไม่ใช่เป้าหมายใช่หรือไม่

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

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

กลุ่มอาชญากรมีอยู่จริง

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

บอทเน็ตจะนำคุณลง

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

รัฐบาลต่างประเทศพร้อมจะช่วยเหลือคุณ

ดูเหมือนเป็นเรื่องตลก แต่รัฐบาลจีนมีคนหลายพันคนที่แฮ็กระบบเพื่อค้นหาความลับทางการค้า ข่าวกรองของรัฐบาล และแม้แต่ข้อมูลเกี่ยวกับศัตรูทางการเมือง

ฟังดูเป็นงานที่สนุกสุดๆ ใช่ไหม

จีนไม่ใช่รัฐชาติเดียวที่กำกับดูแลทรัพยากรการแฮ็กทั่วโลก รัฐบาลทั่วโลกเข้าร่วม ดังนั้นอย่าคิดว่าการสมัครของคุณไม่สำคัญพอที่จะจริงจังกับข้อกังวลด้านความปลอดภัย

นักแฮ็กข้อมูลกำลังซุ่มซ่อนอยู่ในเงามืด

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

การอ่านที่จำเป็น

นี่คือแนวทางที่ไม่เพียงพอ คุณคาดหวังว่ามันจะครอบคลุมหรือไม่? อย่างน้อยคุณควรอ่าน:

• คำแนะนำด้านความปลอดภัยของ Rails
• หน้าการรักษาความปลอดภัย Ruby อย่างเป็นทางการ

ช่องโหว่ด้านความปลอดภัย Ruby แปดช่องโหว่ (หรือแปดวิธีง่ายๆ ในการรับ p0wn'd)

ตอนนี้เราอยู่ในหน้าเดียวกันแล้วเกี่ยวกับความร้ายแรงของการรักษาความปลอดภัย (แม้แต่แอปขนาดเล็ก) คุณอาจสงสัยว่าจะแน่ใจได้อย่างไรว่าแอป Ruby ของคุณปลอดภัย

เราจะครอบคลุมช่องโหว่แปดประเภท ซึ่งเป็นสิ่งสำคัญสำหรับนักพัฒนาเว็บในการทำความเข้าใจ

• ไม่ใช่ด้านเทคนิค
• การเขียนสคริปต์ข้ามไซต์ (XSS)
• การปลอมแปลงคำขอข้ามไซต์ (CSRF, XSRF)
• ชายที่อยู่ตรงกลาง (MITM)
• การฉีด SQL (SQLI)
• การกำหนดมวลและการฉีดพารามิเตอร์
• การปฏิเสธการให้บริการ (DOS, DDOS)
• การโจมตีแพลตฟอร์ม (การใช้ประโยชน์จากโฮสต์ที่รันแอปพลิเคชันของคุณ)

การหาประโยชน์ด้านความปลอดภัยที่ไม่ใช่ด้านเทคนิคซึ่งอาจส่งผลต่อความปลอดภัยของ Ruby on Rails

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

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

อย่า:

• ส่งรหัสผ่านข้อความธรรมดาทางอีเมล
• ใช้รหัสผ่านเดียวกันทุกที่
• เชื่อใจผู้ที่มาปรากฏตัวที่สำนักงานพร้อมกับคุกกี้
• พกพาข้อมูลที่ละเอียดอ่อนไว้บนแล็ปท็อปของคุณ

การเขียนสคริปต์ข้ามไซต์

มีช่องโหว่ประเภทหนึ่งที่ทำให้ผู้ประสงค์ร้ายใช้ประโยชน์จากผู้ใช้ของคุณในขณะที่พวกเขาใช้แอปพลิเคชันของคุณ

หากฉันเป็นนักแสดงที่ไม่ดี ฉันอาจจะสนใจวิธีแทรก JavaScript บางส่วนของฉันลงในเพจของคุณ

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

มีวิธีง่ายๆ ในการป้องกันสคริปต์ข้ามไซต์

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

คุณต้องการสิ่งนี้

<script>alert('I am stealing your cookies! Ha!');</script>

คุณไม่ต้องการสิ่งนี้:

<script>alert('I am stealing your cookies! Ha!');</script>

บางครั้งการป้องกันสคริปต์ข้ามไซต์ไม่ใช่เรื่องง่าย

นี่คือสิ่งที่ หากคุณมีแอปพลิเคชัน Rails รุ่นเก่าที่ทำงานโดยไม่มีแพตช์รักษาความปลอดภัย คุณอาจมีช่องโหว่ XSS ย้อนกลับไปใน Rails เวอร์ชันแรกสุด คุณต้องหลีกเลี่ยงอินพุตที่ไม่น่าเชื่อถือด้วยตนเองโดยใช้ h() วิธีการ.

แอป Modern Rails จะหลีกเลี่ยงเอาต์พุต HTML ตามค่าเริ่มต้น ซึ่งจะป้องกันช่องโหว่ XSS ส่วนใหญ่ทันที แต่ก็ยังง่ายอย่างน่าประหลาดใจที่จะพลาด โดยเฉพาะอย่างยิ่งเมื่อต้องจัดการกับโค้ดเดิม ไลบรารีของบุคคลที่สาม หรือการแสดงผล HTML แบบไดนามิก

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

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

การปลอมแปลงคำขอข้ามไซต์

ช่องโหว่ด้านความปลอดภัยทั่วไปอีกประการหนึ่งในแอปพลิเคชัน Rails เรียกว่าการปลอมแปลงคำขอข้ามไซต์ ลองดูตัวอย่าง

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

คำขอยังคงดำเนินต่อไป ผู้โจมตีสามารถใช้ประโยชน์จากข้อเท็จจริงนี้ได้ด้วยการใช้ประโยชน์อย่างระมัดระวัง

กายวิภาคของการโจมตี CSRF

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

และจะแย่ไปกว่านั้นหากแอปของคุณใช้คำขอ GET แทนคำขอ POST

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

โชคดีที่ Ruby on Rails หลีกเลี่ยงการโจมตีประเภทนี้โดยเสนอการป้องกัน CSRF ในตัวเป็นส่วนใหญ่ คุณอาจเรียกมันว่า "ข้อความแปลกๆ ที่ใส่อยู่ในแบบฟอร์มของฉันทั้งหมดด้วยเหตุผลบางอย่าง"

<input type="hidden" name="authenticity_token" value="kM3jN8vBx2QzE-7wRtFpL6aYsI9uZcXmD4oHgK1rVnWe5qA0bUiJlSfTyP3hG2oC8xZ7mBvNkL4wQrEtYuI6pA" autocomplete="off" />

ข้อความที่อ่านไม่ออกคือคีย์ลับที่จัดเก็บไว้ในข้อมูลเซสชันของผู้ใช้ หากผู้ใช้ส่งโทเค็น CSRF ที่ไม่ตรงกับโทเค็นในเซสชัน แอปของคุณจะแสดงข้อยกเว้น โชคดีที่ Honeybadger สามารถช่วยคุณค้นหาและแก้ไขข้อยกเว้นเหล่านี้ได้!

แต่คุณยังสามารถทำมันพังได้

แน่นอน คุณสามารถปิดการใช้งานการตรวจสอบ CSRF ด้วยบรรทัดโค้ดที่ดูเหมือนไม่มีพิษภัยในคอนโทรลเลอร์:

skip_before_action :verify_authenticity_token

คุณยังอาจทำให้เกิดปัญหากับตัวเองได้โดยใช้เส้นทาง GET สำหรับสิ่งที่ควรเป็นเส้นทาง POST:

MyApp::Application.routes.draw do
 match "/launch_all_the_missiles", to: "missiles#launch_all"
end

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

การโจมตีแบบแทรกกลางและการดมแพ็กเก็ต

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

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

คุกกี้ของแอปพลิเคชันมีความเสี่ยงต่อการโจมตีแบบแทรกกลาง

เรื่องราวข้างต้นอาจฟังดูไร้สาระเล็กน้อย แต่สิ่งเดียวกันนี้สามารถเกิดขึ้นได้กับคุกกี้ของผู้ใช้ของคุณ

โดยปกติคุกกี้จะถูกส่งไปพร้อมกับทุกคำขอของเว็บ หากส่งเป็นข้อความธรรมดาผ่านเครือข่ายสาธารณะ (wifi) เกมจะจบลง

ผู้กระทำความผิดที่ทำงานบางอย่างเช่น Firesheep สามารถรับสำเนาคุกกี้ของผู้ใช้และบุกรุกบัญชีของพวกเขาได้อย่างง่ายดาย

SSL เพื่อช่วยเหลือ

คำตอบง่ายๆ คือใช้ HTTPS สำหรับทุกสิ่งและปฏิบัติตามความปลอดภัยในการขนส่งที่เข้มงวด ผู้คนในร้านกาแฟยังคงสามารถเห็นการจราจรของผู้ใช้ได้ แต่มีการเข้ารหัสไว้ คำตอบที่ไม่ง่ายนักแต่อาจจะดีกว่าในบางสถานการณ์คือการใช้คุกกี้ที่ปลอดภัยของ Rails

คุกกี้ที่ปลอดภัยจะถูกส่งไปยังเบราว์เซอร์ผ่านการเชื่อมต่อ HTTPS เท่านั้น ซึ่งเป็นค่าเริ่มต้นตั้งแต่ Rails 3

หากคุณโชคไม่ดีพอที่จะใช้ Rails เวอร์ชันเก่ากว่านั้น คุกกี้ที่ปลอดภัยสามารถส่งผ่านข้อความธรรมดาได้ ไม่ปลอดภัยขนาดนั้นเหรอ?

การแทรก SQL

เว็บไซต์ส่วนใหญ่บนอินเทอร์เน็ตทำงานโดยการรวมส่วนของข้อความเข้าด้วยกันเพื่อสร้างโปรแกรมเล็กๆ ในภาษาที่เรียกว่า SQL

แค่คิดเกี่ยวกับเรื่องนั้น คุณรู้ไหมว่ามันบ้าขนาดไหน?

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

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

ตัวอย่างการแทรก SQL

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

Building.where("st_intersects(st_setsrid(st_makebox2d(st_point(#{params[:northeast][:lng]}, #{params[:northeast][:lat]}), st_point(#{params[:southwest][:lng]}, %{params[:southwest][:lat]})), 4326), buildings.location)")

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

")), 4326), buildings.location); UPDATE users SET admin=1 WHERE id=666;--"

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

Rails ปกป้องเราจากการฉีด SQL เกือบจะโดยอัตโนมัติ

Rails ป้องกันการฉีด SQL ในหลายกรณี ตราบใดที่คุณปล่อยไว้ หากเราใช้ where อย่างถูกต้อง พารามิเตอร์จะถูกหลีกเลี่ยง และความพยายามในการฉีด SQL จะล้มเหลว

where("st_intersects(st_setsrid(st_makebox2d(st_point(?, ?), st_point(?, ?)), 4326), #{table_name}.location)", box[:northeast][:lng], box[:northeast][:lat], box[:southwest][:lng], box[:southwest][:lat]).

Rail ไม่ได้ป้องกันการแทรก SQL เสมอไป

แต่มีหลายที่ที่ Rails ใช้ raw SQL สถานที่ที่คุณอาจมองข้ามได้ง่าย

ตัวอย่างเช่น คุณรู้หรือไม่ว่าใน SomeModel.sum("amount") สตริง "amount" จะถูกเพิ่มลงในการสืบค้นโดยไม่ถูก Escape

ดังนั้นหากคุณมีรายงานที่คุณโทรไปที่ sum วิธีการที่มีการเข้าถึงโดยตรงของ params["col"] คุณกำลังประสบปัญหา

นี่คือตัวอย่างเซสชัน IRB ซึ่งแสดงผลที่ตามมาจากการส่งอินพุตที่ไม่น่าเชื่อถือไปยังวิธีรวม:

pry(main)> User.sum(%[id) AS sum_id FROM users; update users set
admin='t' where id=224;--])
(22.4ms) SELECT SUM(id) AS sum_id FROM users; update users set
admin='t' where id=224;--) AS sum_id FROM "users" 
=> "0"

เช่นเดียวกับ #pluck ตลอดจนวิธีการอื่นๆ อีกมากมาย

การโจมตีแบบแบ่งกลุ่ม

4 มีนาคม 2555 แฮ็กเกอร์ชาวรัสเซีย Egor Homakov เปิดเผยช่องโหว่การมอบหมายงานจำนวนมากที่อาจปล่อยให้ผู้โจมตีปลอมตัวเป็นผู้ใช้ GitHub อย่างที่คุณสามารถจินตนาการได้ นี่เป็นปัญหาอย่างยิ่ง

วิธีที่ GitHub ถูกแฮ็ก

ฉันพนันได้เลยว่าคุณเขียนโค้ดแบบนี้มาหลายร้อยครั้ง:

User.create(params[:user])

เนื่องจากโค้ด Ruby สามารถอ่านง่าย จึงค่อนข้างง่ายที่จะบอกว่าโค้ดนี้สร้างผู้ใช้ด้วยพารามิเตอร์ที่กำหนด

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

ปัญหาที่เกิดขึ้นคือลืมได้ง่าย ดังนั้นคุณจึงพบว่าตัวเองอยู่ในโลกที่ผู้โจมตีต้องส่งคำขอ POST ที่ถูกต้องเพื่อทำให้เกิดสิ่งนี้:

User.create({admin: true, ...})

หรือในกรณีของ GitHub บางอย่างเช่นนี้:

PublicKey.update({user_id: "123"})

การกำหนดมิสซาเป็นเรื่องง่าย

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

แทนที่จะส่ง params ทั้งหมดแบบสุ่มสี่สุ่มห้า แฮชเป็น User.create คุณประกาศอย่างชัดเจนว่าแอตทริบิวต์ใดที่ได้รับอนุญาต:

def user_params
 params.require(:user).permit(:name, :email)
end

User.create(user_params)

ตัวเลือกง่ายๆ นี้ช่วยปกป้องโมเดลของคุณด้วยการอนุญาตเฉพาะช่องที่คุณต้องการอัปเดต เป็นการป้องกันเริ่มต้นใน Rails 4 ขึ้นไป หากคุณยังคงใช้แอปที่เก่ามาก (เช่น Rails 4 หรือเก่ากว่า) ก็คุ้มค่าที่จะอัปเกรด

การปฏิเสธการโจมตีบริการ

วันนี้คุณหงุดหงิดไปกี่คนแล้ว? แล้วเดือนที่แล้วล่ะ?

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

DDOS เป็นการโจมตีที่หยาบคายแต่มีประสิทธิภาพ

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

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

การโจมตีที่ซับซ้อนของอัลกอริทึม

มันฟังดูเจ๋งมากเลยใช่ไหม

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

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

การหาประโยชน์จากเซิร์ฟเวอร์สมัยเก่าที่ดี

นี่คือสิ่งที่เราคิดจริงๆ เมื่อเรานึกถึงแฮกเกอร์ ใช่ไหม? คนที่ไม่คุ้นเคยใช้บัฟเฟอร์ล้นเพื่อทำให้ Apache เรียกใช้โค้ดที่กำหนดเองในฐานะผู้ใช้รูท

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

การตรวจจับการโจมตีอัตโนมัติ

คุณสามารถใช้เครื่องมือยอดนิยมเช่น Fail2ban เพื่อบล็อกที่อยู่ IP ของโฮสต์ที่กำลังพยายามโจมตีคุณโดยอัตโนมัติ

ทำสิ่งที่คุณรู้ว่าควรทำ

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

ถึงเวลายกระดับความปลอดภัยของ Rails ของคุณแล้ว

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

เมื่อรองรับเฟรมเวิร์กแล้ว ให้ใช้คู่มือนี้ (และคู่มือความปลอดภัยของ Rails!) เพื่อลดความเสี่ยงบนพื้นผิวของแอปของคุณ ใช้พารามิเตอร์ที่แข็งแกร่ง กำหนดค่าตัวจำกัดอัตราและอาจเป็นพร็อกซี ปฏิบัติตามแบบแผน HTTP สำหรับวิธีการและบังคับให้การรับส่งข้อมูลเป็น SSL สิ่งเหล่านี้จะลดโอกาสที่คุณจะประสบปัญหาด้านความปลอดภัยทีละน้อย

หมายเหตุบรรณาธิการ:โพสต์นี้เผยแพร่ครั้งแรกในเดือนมีนาคม 2013 และได้รับการอัปเดตเพื่อความถูกต้อง