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

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

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

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

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

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

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

ทำไมคุณต้องสนใจความปลอดภัยของ Rails?

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

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

คุณคิดว่าแอปพลิเคชันของคุณไม่ใช่เป้าหมาย?

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

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

อาชญากรที่มีองค์กรเป็นเรื่องจริง

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

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

ตอนรันบอทเน็ต บอทมากเท่าไร เงินก็มากเท่านั้น ดังนั้นจึงซื้อ exploit pack ตั้งค่าให้ติดตั้งมัลแวร์เมื่อเบราว์เซอร์เก่าเข้า payload แล้วแฮกเว็บไซต์ที่ถูกต้องเพื่อส่ง payload ให้ผู้ใช้จำนวนมาก

รัฐบาลต่างชาติออกมาล่าคุณ

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

ฟังดูเหมือนงานสนุกมากเลยเนอะ?

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

แฮกทิวิสต์กำลังรอคอยในเงามุม

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

เอกสารที่ควรอ่าน

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

• คู่มือความปลอดภัยของ Rails
• หน้าความปลอดภัยทางการของ Ruby

ช่องโหว่ด้านความปลอดภัยของ Ruby 8 ประการ (หรือ 8 วิธีง่ายๆ ที่จะถูก p0wn)

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

เราจะครอบคลุม 8 ประเภทของช่องโหว่ ที่นักพัฒนาเว็บจำเป็นต้องเข้าใจ

• Non-technical (ไม่เกี่ยวกับเทคนิค)
• Cross-Site Scripting (XSS)
• Cross-Site Request Forgery (CSRF, XSRF)
• Man in the Middle (MITM)
• SQL Injection (SQLI)
• Mass Assignment & Parameter Injection
• Denial of Service (DOS, DDOS)
• Platform Attacks (การโจมตีโฮสต์ที่รันแอปพลิเคชันของคุณ)

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

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

จำนวนและความหลากหลายของสิ่งโง่ๆ ที่คุณทำได้เป็นอนันต์ เราจะ chỉบอกเพียงบางอย่าง

อย่าทำ:

• ส่งรหัสผ่านแบบ plaintext ผ่านอีเมล
• ใช้รหัสผ่านเดียวกันทุกที่
• พกพาข้อมูลสำคัญบนแล็ปท็อป

Cross-site Scripting (XSS)

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

ถ้าผมเป็นผู้กระทำความผิด ผมอาจสนใจวิธีการแทรก JavaScript ของผมเข้าไปในหน้าของคุณ

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

มีวิธีป้องกัน cross-site scripting อย่างง่าย

เพื่อทำลายแผนการของผู้โจมตีที่มองหาช่องโหว่ XSS คุณต้อง escape ข้อความจาก user input ให้ JavaScript กลายเป็นข้อความธรรมดาที่ไม่เป็นอันตราย

คุณต้องการแบบนี้:

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

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

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

บางครั้งการป้องกัน XSS ไม่ได้ง่ายขนาดนั้น

เรื่องคือ ถ้าคุณมีแอป Rails เก่าที่รันโดยไม่มี security patches คุณน่าจะมีช่องโหว่ XSS ในอดีตกาลของ Rails เริ่มต้น คุณต้อง escape untrusted input เองด้วยเมธอด h()

แอป Rails รุ่นใหม่ escape HTML output โดยอัตโนมัติ ซึ่งป้องกันช่องโหว่ XSS ส่วนใหญ่ได้ทันที แต่ยังคงทำผิดได้ง่ายมาก โดยเฉพาะตอนจัดการกับ legacy code, ไลบรารีของ協力廠商 หรือการเรนเดอร์ HTML แบบไดนามิก

แม้ใน Rails รุ่นใหม่ คุณยังยิงเท้าตัวเองได้ การเรียก html_safe บน user input จะข้ามการ escape ทั้งหมด ดังนั้นถ้าคุณ interpolate user input เข้า HTML และทำเครื่องหมายว่า safe คุณก็ปิดการป้องกันในตัวของ Rails และเชิญชวน XSS เข้ามาในแอป

ทีม Rails ยอมรับว่า cross-site scripting เป็น exploit ที่แพร่หลายและทำลายล้างมากที่สุด จึงจัดสรรส่วนของเอกสารความปลอดภัยเพื่อให้เรามีสิ่งที่จำเป็นในการลดความเสี่ยงนี้ คุ้มค่าที่จะอ่าน แม้คุณคิดว่าแอปของคุณปลอดภัยก็ตาม

Cross-site Request Forgery (CSRF)

ช่องโหว่ด้านความปลอดภัยอีกประเภทหนึ่งที่พบบ่อยในแอป Rails เรียกว่า cross-site request forgery มาดูตัวอย่างกัน

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

คำขอ vẫnจะผ่านได้ ผู้โจมตีสามารถใช้ข้อเท็จจริงนี้ได้ด้วย exploit ที่วางแผนไว้

โครงสร้างของการโจมตี CSRF

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

และมันแย่กว่านั้นถ้าแอปของคุณใช้ GET requests แทน POST requests

ผมแม้แต่ไม่ต้องหลอกคุณ ผมสามารถทำให้ authenticated request เกิดขึ้นได้เพียงแค่เพิ่มแท็ก image ในหน้าที่คุณเพิ่งเยี่ยมชม

โชคดีที่ Ruby on Rails หลีกเลี่ยงชนิดการโจมตีนี้ด้วยการป้องกัน CSRF ที่ built-in ส่วนใหญ่ คุณอาจรู้จักมันในชื่อ "ข้อความแปลกๆ ที่ถูกใส่ในฟอร์มทุกอันของผม"

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

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

แตคุณยังทำผิดได้

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

skip_before_action :verify_authenticity_token 

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

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

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

การโจมตี Man-in-the-middle และ Packet Sniffing

การโจมตี Man-in-the-middle อธิบายได้ดีที่สุดด้วยการเปรียบเทียบ สมมติว่าคุณต้องส่งเงินสดให้ลูกพี่ลูกน้องวินนี่ที่เก aléa คุณอาจใส่เงินในซอง เขียนที่อยู่ เพิ่มแสตมป์ และมอบซองให้พนักงานไปรษณีย์

หนึ่งสัปดาห์ต่อมา ซองถึงมือวินนี่แต่ไม่มีเงินอยู่ในซอง เกิดอะไรขึ้น? ใครบางคน竄改เนื้อหาในซองระหว่างคุณและผู้รับ นี่คือการโจมตี man-in-the-middle แบบง่าย

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

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

คุกกี้มักส่งพร้อมกับทุก web request ถ้าส่งเป็น cleartext ผ่านเครือข่ายสาธารณะ (wifi) ถือว่าเสร็จสิ้น

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

SSL มาช่วยชีวิต

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

Secure cookies จะส่งไปที่เบราว์เซอร์เฉพาะผ่าน HTTPS connection ซึ่งเป็นค่าเริ่มต้นมาตั้งแต่ Rails 3

ถ้าคุณโชคร้ายที่รัน Rails เก่ากว่านั้น secure cookies อาจส่งเป็น plain text ไม่ปลอดภัยเลยหรอก

SQL Injection

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

ลองคิดดู คุณมีความคิดว่ามันบ้าขนาดไหน?

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

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

ตัวอย่าง SQL Injection

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

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 injection การเข้าถึง params โดยตรงใน SQL query ให้ไคลเอนต์บังคับให้ SQL ของตัวเองรันได้ โจมตีที่ฉลาดสามารถทำให้ params[:southwest][:lat] มีโค้ด SQL อันตรายแบบนี้:

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

และตอนนี้ user ID ของผมมีสิทธิ์แอดมินแล้ว SQL injections เป็น exploit ที่พบบ่อยและง่าย ดังนั้นใครก็ตามที่ดู traffic ของเว็บไซต์นานพอ จะเห็นพยายาม SQL inject ระหว่างทาง

Rails ป้องกัน SQL injection เกือบอัตโนมัติ

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

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]). 

Rails ไม่ได้ป้องกัน SQL injection เสมอไป

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

เช่น คุณรู้ไหมว่าใน SomeModel.sum("amount") สตริง "amount" จะถูกเพิ่มเข้า query โดยไม่ถูก escape?

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

นี่คือตัวอย่าง IRB session แสดงผลลัพธ์ของการส่ง untrusted input เข้าเมธอด sum:

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 และเมธอดอื่นๆ อีกมาก

การโจมตี Mass Assignment

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

GitHub ถูกแฮกอย่างไร

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

User.create(params[:user]) 

ขอบคุณความอ่านง่ายของโค้ด Ruby ทำให้เห็นง่ายว่าโค้ดนี้สร้างผู้ใช้ด้วยพารามิเตอร์ที่ให้มา

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

ปัญหาที่เกิดคือมันง่ายที่จะลืม และคุณก็จะอยู่ในโลกที่ผู้โจมตีแค่ส่ง POST request ที่ถูกต้องก็ทำให้เกิด:

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

หรือในกรณีของ GitHub อาจเป็นแบบนี้:

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

Mass assignment แก้ไขได้ง่าย

วิธีแก้ที่แนะนำสำหรับช่องโหว่ mass assignment ในแอป Rails รุ่นใหม่คือใช้ Strong Parameters ซึ่งคุณควรคุ้นเคยจากส่วนก่อนหน้านี้

แทนที่จะส่ง params hash ทั้งหมดไป User.create คุณระบุชัดเจนว่า attribute ไหนอนุญาต:

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

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

การโจมตี Denial of Service

วันนี้คุณทำให้ใครโกรธกี่คน? เดือนที่แล้วล่ะ?

การโจมตี Denial of service (DOS) และ distributed denial of service (DDOS) เป็นเวอร์ชันของ rage comic ในชุมชน infosec การโจมตีเหล่านี้ไม่ได้ขโมยข้อมูลหรือเผยแพร่มัลแวร์ พวกมันแค่อยากปิดตัวคุณลง แม้จะเป็นเช่นนั้น ก็ยังทำลายทางการเงินหรือชื่อเสียงของบริษัทคุณได้อย่างหนัก

DDOS เป็นการโจมตีที่ดิบแต่มีผล

เพื่อทำ DDOS แค่โทรหาเพื่อน 500 คน ให้ไปเว็บ Amnesty International และกด refresh ตลอดหนึ่งชั่วโมง บอทแทนเพื่อนก็ได้

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

การโจมตี Algorithmic Complexity

ฟังดูน่ากลัวมากเลยเนอะ?

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

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

การโจมตีเซิร์ฟเวอร์แบบเก่าๆ ที่ดี

นี่คือสิ่งที่เราคิดถึงตอนคิดถึงแฮกเกอร์ใช่ไหม? คนแอบแฝงใช้ buffer overflow ทำให้ Apache รัน arbitrary code เป็น root user?

แต่งานน่าเบื่อหลายอย่างเหมือนกัน เรื่องนี้ก็ถูกทำให้อัตโนมัติ ถ้าคุณดู system logs ตอนนี้ เดิมพันว่าคุณจะเห็นบอทพยายาม brute-force SSH login

ทำให้การตรวจจับการโจมตีเป็นอัตโนมัติ

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

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

อัปเดตระบบปฏิบัติการให้ทันสมัย อย่ารันบริการที่ไม่จำเป็น ไม่อนุญาต password authentication สำหรับ SSH รายการยาวนาน ถ้าคุณใช้ platform ส่วนใหญ่จะจัดการให้แล้ว

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

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

เมื่อเฟรมเวิร์กได้รับการสนับสนุนแล้ว ใช้คู่มือนี้ (และคู่มือความปลอดภัยของ Rails!) เพื่อลดพื้นที่ผิวความเสี่ยงของแอป ใช้ strong parameters ตั้งค่า rate limiter และ proxy บังคับให้ traffic เป็น SSL ทุกอย่างนี้จะลดโอกาสที่คุณจะเผชิญปัญหาด้านความปลอดภัยทีละนิด

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