Nếu bạn giống tôi, bạn tham gia công việc kinh doanh này vì bạn thích xây dựng những ứng dụng tuyệt vời. Nếu bạn đã ở trong lĩnh vực phát triển đủ lâu thì cuối cùng bạn sẽ phải làm việc trên những ứng dụng tuyệt vời mà không cảm thấy quá tuyệt vời . Bảo mật có thể là một trong những điều đó. Việc coi trọng vấn đề bảo mật của Rails là rất quan trọng, mặc dù khung Rails thực hiện phần lớn công việc nặng nhọc.
Trước khi đi sâu vào chi tiết về bảo mật Ruby on Rails, chúng ta hãy dành một giây để suy ngẫm về những khoảng thời gian tuyệt vời.
... và bây giờ quay lại thế giới thực.
Thật tệ khi bạn thậm chí phải lo lắng về các mối đe dọa bảo mật. Thật là buồn nôn khi có những người thức dậy vào mỗi buổi sáng và cố gắng đập vỡ những thứ bạn đang xây dựng.
Nhưng những người này tồn tại. Họ làm việc chăm chỉ để chọc thủng lỗ hổng bảo mật của bạn. Và khi họ thành công, đó là lỗi của bạn.
Khách hàng của bạn không thể thay mặt bạn đảm bảo an toàn cho mã của bạn. Người quản lý của bạn không thể làm điều đó cho bạn. Tất cả là do bạn. Vì thế tốt nhất bạn nên biết mình đang làm cái quái gì.
Tại sao bạn nên quan tâm đến bảo mật Rails?
- Bạn cố gắng làm theo các phương pháp hay nhất về bảo mật nhưng không thực sự hiểu chúng?
- Bạn chưa rõ về cách thức hoạt động của các cuộc tấn công XSRF, MITM và XSR?
- Bạn có nghĩ rằng vì ứng dụng của bạn có quy mô nhỏ hoặc nội bộ nên chúng không gặp rủi ro không?
Nếu bất kỳ điều nào trong số này là đúng thì hướng dẫn này chắc chắn là dành cho bạn. Bảo mật rất quan trọng đối với mọi ứng dụng và việc tránh đầu tư vào ứng dụng đó chỉ tốt cho đến khi không còn nữa. Rails giúp việc giảm thiểu một số rủi ro bảo mật lớn nhất của ứng dụng web trở nên cực kỳ đơn giản, vì vậy sẽ thật ngớ ngẩn nếu không thu hẹp khoảng cách.
Bạn có nghĩ ứng dụng của mình không phải là mục tiêu không?
Bạn có thể sai. Nếu nó ở trên internet, nó đang bị bao vây. Các hệ thống tự động đang quét các ứng dụng web dễ bị tấn công suốt ngày đêm.
Dù là tội phạm có tổ chức hay bot, Internet vẫn có đầy rẫy những kẻ xấu muốn lấy dữ liệu của người dùng của bạn.
Tội phạm có tổ chức là có thật
Bạn có đang lưu trữ thẻ tín dụng trong cơ sở dữ liệu của mình không? Băm mật khẩu không có muối? Tôi hy vọng là không! Nếu vậy thì bạn tiêu rồi. Rails giúp việc tránh những sai lầm như thế này tương đối dễ dàng.
Botnet sẽ hạ gục bạn
Khi bạn chạy một mạng botnet, nhiều bot hơn đồng nghĩa với nhiều tiền hơn. Vì vậy, bạn mua gói khai thác, thiết lập gói này để cài đặt phần mềm độc hại khi trình duyệt cũ truy cập vào phần tải trọng, sau đó hack một số trang web hợp pháp để phân phối phần mềm độc hại đến nhiều người dùng.
Các chính phủ nước ngoài đang nỗ lực giúp đỡ bạn
Nghe có vẻ như một trò đùa nhưng chính phủ Trung Quốc có hàng nghìn người hack hệ thống để tìm kiếm bí mật thương mại, thông tin tình báo của chính phủ và thậm chí cả thông tin về kẻ thù chính trị.
Đó chẳng phải là một công việc cực kỳ thú vị sao?
Trung Quốc không phải là quốc gia duy nhất chỉ đạo các tài nguyên hack trên toàn cầu. Các chính phủ trên khắp thế giới đều tham gia, vì vậy đừng nghĩ rằng ứng dụng của bạn không đủ quan trọng để coi trọng vấn đề bảo mật.
Những kẻ tấn công đang ẩn nấp trong bóng tối
Bạn có bán sên uranium cạn kiệt cho Bộ Quốc phòng không? Sau đó, bạn phải có đủ tiền để thuê một người biết họ đang làm gì. Những kẻ tấn công thường xuyên nhắm mục tiêu vào các trang web phù hợp với mục tiêu hoạt động của chúng.
Đọc bắt buộc
Đây là hướng dẫn không đầy đủ. Bạn có mong đợi nó sẽ toàn diện không? Tối thiểu bạn cũng nên đọc:
- Hướng dẫn bảo mật Rails
- Trang bảo mật chính thức của Ruby
Tám lỗ hổng bảo mật của Ruby (hoặc tám cách dễ dàng để bị tấn công)
Bây giờ chúng ta đã thống nhất về mức độ bảo mật nghiêm trọng (ngay cả đối với các ứng dụng nhỏ), có thể bạn đang tự hỏi làm cách nào để đảm bảo ứng dụng Ruby của mình được an toàn.
Chúng tôi sẽ đề cập đến tám loại lỗ hổng bảo mật điều quan trọng mà các nhà phát triển web phải hiểu.
- Phi kỹ thuật
- Kịch bản chéo trang web (XSS)
- Giả mạo yêu cầu trên nhiều trang web (CSRF, XSRF)
- Người đàn ông ở giữa (MITM)
- Chèn SQL (SQLI)
- Gán hàng loạt &chèn tham số
- Từ chối dịch vụ (DOS, DDOS)
- Tấn công nền tảng (Khai thác máy chủ chạy ứng dụng của bạn)
Các hành vi khai thác bảo mật phi kỹ thuật có thể ảnh hưởng đến bảo mật của Ruby on Rails
Đôi khi, những vấn đề hiển nhiên lại là vấn đề khó nhìn thấy nhất. Bạn có thể không thấy những lỗi này trong danh sách kiểm tra, nhưng bạn nên sử dụng một số kiến thức thông thường.
Số lượng và sự đa dạng của những điều ngu ngốc bạn có thể làm là vô tận, vì vậy chúng tôi sẽ chỉ nêu ra một số điều.
Đừng:
- Gửi mật khẩu văn bản gốc qua email
- Sử dụng cùng một mật khẩu ở mọi nơi
- Hãy tin tưởng những người xuất hiện tại văn phòng của bạn với cookie
- Mang dữ liệu nhạy cảm vào máy tính xách tay của bạn
Kịch bản chéo trang
Có một loại lỗ hổng cho phép kẻ xấu lợi dụng người dùng khi họ sử dụng ứng dụng của bạn.
Nếu tôi là kẻ xấu, tôi có thể khá quan tâm đến cách chèn một số JavaScript của mình vào trang của bạn.
Sau khi làm điều đó, tôi có thể đánh cắp cookie phiên hoạt động, khởi động bộ công cụ khai thác vào DOM hoặc thậm chí khiến các trang nói những điều kỳ quặc. Điều đó nghe có vẻ không có hại lắm nhưng ngay cả việc tiêm nội dung độc hại cũng có thể gây tổn hại về mặt danh tiếng.
Có một cách đơn giản để chống lại kịch bản chéo trang
Để ngăn chặn những kẻ tấn công đang tìm cách lợi dụng tập lệnh chéo trang, bạn cần thoát khỏi mọi văn bản khỏi dữ liệu nhập của người dùng để JavaScript bị biến thành văn bản vô hại.
Bạn muốn điều này.
<script>alert('I am stealing your cookies! Ha!');</script>
Bạn không muốn điều này:
<script>alert('I am stealing your cookies! Ha!');</script>
Đôi khi không dễ dàng để chống lại kịch bản chéo trang
Đây là điều Nếu bạn có một ứng dụng Rails cũ đang chạy mà không có bản vá bảo mật, có thể bạn đã gặp lỗ hổng XSS. Quay lại phiên bản đầu tiên của Rails, bạn phải thoát khỏi đầu vào không đáng tin cậy theo cách thủ công bằng cách sử dụng h() phương pháp.
Các ứng dụng Rails hiện đại thoát khỏi đầu ra HTML theo mặc định, điều này ngăn chặn hầu hết các lỗ hổng XSS. Tuy nhiên, nó vẫn dễ mắc lỗi một cách đáng ngạc nhiên, đặc biệt là khi xử lý mã cũ, thư viện của bên thứ ba hoặc kết xuất HTML động.
Ngay cả trong các phiên bản hiện đại của Rails, bạn có thể tự bắn vào chân mình. Đang gọi html_safe trên đầu vào của người dùng sẽ bỏ qua việc thoát hoàn toàn, vì vậy nếu bạn đang nội suy đầu vào của người dùng vào HTML và đánh dấu nó an toàn thì về cơ bản, bạn đang tắt tính năng bảo vệ tích hợp của Rails và mời XSS vào ứng dụng của mình.
Nhóm Rails thừa nhận tập lệnh chéo trang là một cách khai thác đặc biệt phổ biến và gây tổn hại, vì vậy họ dành một phần tài liệu bảo mật để đảm bảo chúng tôi có những gì cần thiết để giảm thiểu rủi ro này. Nó đáng để đọc, ngay cả khi bạn cho rằng ứng dụng của mình an toàn.
Giả mạo yêu cầu trên nhiều trang web
Một lỗ hổng bảo mật phổ biến khác trong ứng dụng Rails được gọi là giả mạo yêu cầu chéo trang. Hãy xem một ví dụ.
Nếu người dùng muốn thay đổi mật khẩu, họ sẽ đăng một biểu mẫu lên phần phụ trợ, phải không? Vậy điều gì sẽ xảy ra nếu biểu mẫu không có trên trang web của bạn?
Yêu cầu vẫn được thực hiện. Những kẻ tấn công có thể lợi dụng thực tế này bằng cách khai thác cẩn thận.
Cấu trúc của một cuộc tấn công CSRF
Giả sử tôi là kẻ tấn công muốn khai thác ứng dụng của bạn thông qua CSRF. Nếu tôi tình cờ biết rằng bạn đã đăng nhập vào ứng dụng của mình với tư cách quản trị viên, tôi có thể tạo một biểu mẫu "thay đổi mật khẩu" được ngụy trang thành một biểu mẫu khác. Bạn sẽ gửi biểu mẫu mà không nhận ra và thay đổi mật khẩu của mình.
Và thậm chí còn tệ hơn nếu ứng dụng của bạn đang sử dụng yêu cầu GET thay vì yêu cầu POST.
Tôi thậm chí sẽ không phải lừa bạn. Tôi có thể khiến yêu cầu được xác thực diễn ra chỉ bằng cách thêm thẻ hình ảnh vào trang bạn đã truy cập gần đây.
May mắn thay, Ruby on Rails tránh được loại tấn công này bằng cách cung cấp tính năng bảo vệ CSRF tích hợp. Bạn có thể biết nó là "văn bản kỳ lạ được đưa vào tất cả các biểu mẫu của tôi vì lý do nào đó."
<input type="hidden" name="authenticity_token" value="kM3jN8vBx2QzE-7wRtFpL6aYsI9uZcXmD4oHgK1rVnWe5qA0bUiJlSfTyP3hG2oC8xZ7mBvNkL4wQrEtYuI6pA" autocomplete="off" />
Văn bản không thể giải mã được là một khóa bí mật được lưu trữ trong dữ liệu phiên của người dùng. Nếu người dùng gửi mã thông báo CSRF không khớp với mã thông báo trong phiên thì ứng dụng của bạn sẽ đưa ra một ngoại lệ. May mắn thay, Honeybadger có thể giúp bạn tìm và khắc phục những trường hợp ngoại lệ này!
Nhưng bạn vẫn có thể làm hỏng nó
Tất nhiên, bạn có thể tắt tính năng kiểm tra CSRF bằng một dòng mã dường như vô hại trong bộ điều khiển:
skip_before_action :verify_authenticity_token
Bạn cũng có thể tự gây ra sự cố khi sử dụng các tuyến GET cho những thứ lẽ ra phải là các tuyến POST:
MyApp::Application.routes.draw do
match "/launch_all_the_missiles", to: "missiles#launch_all"
end
Nhưng bạn sẽ không làm điều đó phải không? Tuy nhiên, điều đáng sợ về CSRF là vấn đề không nhất thiết phải do ứng dụng của bạn gây ra. Người dùng có thể truy cập một trang web khác có nhúng khai thác CSRF, kích hoạt yêu cầu tới ứng dụng của bạn. Dựa vào các biện pháp đối phó của Rails có thể giúp bạn bảo vệ khỏi những điều như vậy.
Tấn công trung gian và đánh cắp gói tin
Các cuộc tấn công trung gian được giải thích tốt nhất bằng một sự tương tự. Giả sử bạn cần gửi một số tiền mặt cho người anh họ Vinny thối nát, vô dụng của mình. Bạn có thể lấy tiền mặt, cho vào phong bì, viết địa chỉ của tên khốn đó, dán tem và giao phong bì cho người đưa thư.
Một tuần sau, chiếc phong bì đến nhà Vinny mà bên trong không có tiền mặt. Chuyện gì đã xảy ra thế? Ai đó đã giả mạo nội dung của phong bì giữa bạn và người nhận dự định. Đây là một cuộc tấn công trung gian đơn giản.
Cookie ứng dụng dễ bị tấn công bởi kẻ trung gian
Câu chuyện trên nghe có vẻ ngớ ngẩn nhưng điều tương tự cũng có thể xảy ra với cookie của người dùng.
Cookie thường được gửi cùng với mọi yêu cầu trên web. Nếu chúng được gửi ở dạng văn bản rõ ràng qua mạng (wifi) công cộng thì trò chơi sẽ kết thúc.
Kẻ ác chạy thứ gì đó như Firesheep có thể dễ dàng lấy được bản sao cookie của người dùng và xâm phạm tài khoản của họ.
SSL để giải cứu
Câu trả lời dễ dàng là sử dụng HTTPS cho mọi thứ và tuân thủ nghiêm ngặt về bảo mật truyền tải. Những người trong quán cà phê vẫn có thể nhìn thấy lưu lượng truy cập của người dùng nhưng nó đã được mã hóa. Câu trả lời không dễ dàng nhưng có lẽ tốt hơn trong một số trường hợp là sử dụng cookie bảo mật của Rails.
Cookie an toàn sẽ chỉ được gửi tới trình duyệt qua kết nối HTTPS, kết nối này đã được mặc định kể từ Rails 3.
Nếu bạn không may mắn chạy phiên bản Rails cũ hơn thế, cookie bảo mật có thể được gửi qua văn bản thuần túy. Không an toàn lắm phải không?
Chèn SQL
Hầu hết các trang web trên internet hoạt động bằng cách dán các đoạn văn bản lại với nhau để tạo thành các chương trình nhỏ bằng ngôn ngữ gọi là SQL.
Chỉ cần nghĩ về điều đó. Bạn có biết chuyện này điên rồ thế nào không?
Nhưng dù muốn hay không thì đây vẫn là cách mọi việc diễn ra. Và dựa trên thực tế là Internet tồn tại, nó phải hoạt động khá tốt.
Một tác dụng phụ của việc đưa SQL lên internet là nếu tin tặc có thể thêm các đoạn văn bản của riêng chúng vào các chương trình SQL nhỏ, thì dữ liệu của bạn có thể gặp vấn đề.
Một ví dụ về chèn SQL
Hãy tưởng tượng rằng nhà thầu của bạn gửi cho bạn một số mã trông như thế này.
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)")
Đây là một sai lầm lớn có thể dẫn đến việc bạn bị tiêm SQL. Việc truy cập trực tiếp các thông số trong truy vấn SQL sẽ cung cấp cho khách hàng tùy chọn buộc SQL của chính họ thực thi. Kẻ tấn công khôn ngoan có thể thực hiện params[:southwest][:lat] chứa một số mã SQL độc hại như thế này:
")), 4326), buildings.location); UPDATE users SET admin=1 WHERE id=666;--"
Và bây giờ ID người dùng của tôi có đặc quyền quản trị viên. Việc chèn SQL là cách khai thác phổ biến và dễ dàng, vì vậy, bất kỳ ai theo dõi lưu lượng truy cập trang web của họ đủ lâu cuối cùng sẽ thấy một số nỗ lực chèn SQL.
Rails gần như tự động bảo vệ chúng ta khỏi việc tiêm SQL
Rails bảo vệ khỏi việc tiêm SQL trong nhiều trường hợp, miễn là bạn cho phép. Nếu chúng ta sử dụng where chính xác thì các tham số sẽ bị thoát và các nỗ lực chèn SQL sẽ không thành công.
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 không phải lúc nào cũng bảo vệ khỏi việc tiêm SQL
Nhưng có rất nhiều nơi Rails sử dụng SQL thô. Những nơi bạn có thể dễ dàng bỏ qua.
Ví dụ:bạn có biết rằng trong SomeModel.sum("amount") , chuỗi "số tiền" được thêm vào truy vấn mà không bị thoát?
Vì vậy, nếu bạn có một báo cáo mà bạn gọi sum phương thức có quyền truy cập trực tiếp params["col"] , bạn đang gặp rắc rối.
Sau đây là một phiên IRB mẫu, cho thấy hậu quả của việc chuyển dữ liệu đầu vào không đáng tin cậy vào phương thức 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"
Điều này cũng đúng với #pluck , cũng như một loạt các phương pháp khác.
Tấn công hàng loạt
Ngày 4 tháng 3 năm 2012, hacker người Nga Egor Homkov đã tiết lộ một lỗ hổng chuyển nhượng hàng loạt có thể cho phép kẻ tấn công giả dạng bất kỳ người dùng GitHub nào. Như bạn có thể tưởng tượng, điều này cực kỳ rắc rối.
GitHub bị hack như thế nào
Tôi cá là bạn đã viết mã như thế này hàng trăm lần:
User.create(params[:user])
Nhờ tính dễ đọc của mã Ruby, khá dễ dàng để biết rằng mã này tạo ra một người dùng với các tham số đã cho.
Trước Rails 3.2.3, điều đó có nghĩa là bất kỳ tham số nào đó là đầu vào sẽ được gán cho mô hình trừ khi bạn chỉ định rõ ràng khác.
Vấn đề được giới thiệu này là nó rất dễ bị quên. Và vì vậy, bạn thấy mình đang ở trong một thế giới mà kẻ tấn công chỉ cần gửi đúng yêu cầu POST để khiến điều này xảy ra:
User.create({admin: true, ...})
Hoặc trong trường hợp của GitHub, đại loại như thế này:
PublicKey.update({user_id: "123"})
Việc phân công hàng loạt là một cách khắc phục dễ dàng
Giải pháp ưu tiên cho các lỗ hổng phân công hàng loạt trong các ứng dụng Rails hiện đại là sử dụng Strong Parameters, mà bạn đã làm quen ở phần trước của bài viết này.
Thay vì mù quáng chuyển toàn bộ params băm thành User.create , bạn khai báo rõ ràng những thuộc tính nào được phép:
def user_params
params.require(:user).permit(:name, :email)
end
User.create(user_params)
Lựa chọn đơn giản này sẽ bảo vệ mô hình của bạn bằng cách chỉ đưa những trường bạn định cập nhật vào danh sách cho phép. Đó là sự bảo vệ mặc định trong Rails 4 trở lên. Nếu bạn đang duy trì một ứng dụng thực sự cũ (như Rails 4 trở lên) thì ứng dụng đó đáng để nâng cấp.
Tấn công từ chối dịch vụ
Hôm nay bạn đã chọc tức bao nhiêu người rồi? Thế còn tháng trước thì sao?
Các cuộc tấn công từ chối dịch vụ (DOS) và các cuộc tấn công từ chối dịch vụ phân tán (DDOS) là phiên bản truyện tranh thịnh nộ của cộng đồng infosec. Những cuộc tấn công này sẽ không đánh cắp dữ liệu của bạn hoặc phát tán phần mềm độc hại. Họ chỉ muốn đóng cửa bạn. Điều này vẫn có thể gây ra thiệt hại lớn về tài chính hoặc danh tiếng cho công ty của bạn.
DDOS là một cuộc tấn công thô thiển nhưng hiệu quả
Để thực hiện một cuộc tấn công từ chối dịch vụ phân tán, chỉ cần gọi cho 500 người bạn thân nhất của bạn, yêu cầu họ truy cập trang web của Tổ chức Ân xá Quốc tế và tiếp tục nhấn làm mới trong một giờ. Bot có thể thay thế bạn bè
Nếu bạn gặp những vấn đề như thế này, có một số giải pháp. Rails không tập trung nhiều vào kiểu tấn công này, nhưng có một số gem có thể giúp bạn nhanh chóng đưa ra giới hạn tốc độ. Rails cũng có phần mềm trung gian điều chỉnh mà bạn có thể sử dụng. Bạn cũng có thể cân nhắc nói chuyện với ISP của mình và sử dụng proxy như Cloudflare, nơi cung cấp các tính năng giới hạn tốc độ mạnh mẽ. Đây là những vấn đề khá nhàm chán nhưng được nhiều người biết đến.
Các cuộc tấn công phức tạp về thuật toán
Điều đó nghe thật tuyệt phải không?
Những cuộc tấn công này lợi dụng một điểm yếu cụ thể trong hệ điều hành, ngăn xếp ứng dụng của bạn, v.v., gây ra sự cố trên máy chủ ứng dụng. Chúng có thể được sử dụng để lấp đầy bộ nhớ máy chủ của bạn, tăng mức sử dụng CPU hoặc thậm chí lấp đầy dung lượng ổ đĩa.
Ví dụ:cuộc tấn công SYN Flood cổ điển hoạt động bằng cách gửi yêu cầu SYN đến máy chủ. Máy chủ mở ra rất nhiều kết nối không bị đóng. Với đủ kết nối mở, hệ điều hành sẽ nhanh chóng hết bộ nhớ và bản thân ứng dụng sẽ bị lỗi. Điều này khai thác thực tế thuật toán để gây ra một vấn đề có ý nghĩa có thể đánh sập hoàn toàn một ứng dụng.
Khai thác máy chủ kiểu cũ tốt
Đây thực sự là những gì chúng ta nghĩ đến khi nghĩ đến hacker, phải không? Những kẻ mờ ám lợi dụng lỗi tràn bộ đệm để khiến Apache chạy mã tùy ý với tư cách là người dùng root?
Nhưng giống như nhiều công việc nhàm chán khác, công việc này cũng đã được tự động hóa. Nếu bạn nhìn vào nhật ký hệ thống của mình ngay bây giờ, tôi cá là bạn sẽ thấy các bot đang cố gắng ép buộc đăng nhập SSH.
Tự động phát hiện cuộc tấn công
Bạn có thể sử dụng một công cụ phổ biến như Fail2ban để tự động chặn địa chỉ IP của máy chủ đang cố gắng tấn công bạn.
Hãy làm những việc bạn biết mình nên làm.
Giữ hệ điều hành của bạn được vá. Đừng chạy các dịch vụ bạn không cần. Không cho phép xác thực mật khẩu cho SSH. Danh sách vẫn tiếp tục. Nếu bạn sử dụng một nền tảng, phần lớn việc này sẽ được xử lý cho bạn.
Đã đến lúc tăng cường bảo mật Rails của bạn
Đầu tiên, đừng hoảng sợ! Bảo mật Rails là một phần công việc của bạn cho dù bạn có thích hay không. Bây giờ bạn đang xem xét vấn đề này một cách nghiêm túc, bạn sẽ đạt được tiến bộ nhanh chóng trong việc giảm thiểu các lỗ hổng. Một chiến thắng được đánh giá thấp nhưng hiệu quả là đảm bảo bạn đang sử dụng phiên bản Rails vẫn đang nhận được các bản cập nhật bảo mật. Tất cả các lối thoát SQL trên thế giới không thể bảo vệ bạn nếu khung này đang chạy trên một phiên bản hiện đã xuất hiện các lỗ hổng nghiêm trọng. Điều tương tự cũng xảy ra với phần phụ thuộc đá quý của bạn.
Sau khi khung này được hỗ trợ, hãy sử dụng hướng dẫn này (và hướng dẫn bảo mật Rails!) để giảm mức độ rủi ro bề mặt của ứng dụng của bạn. Sử dụng các thông số mạnh mẽ. Định cấu hình bộ giới hạn tốc độ và có thể là proxy. Tuân theo các quy ước HTTP cho các phương thức và buộc lưu lượng truy cập phải là SSL. Tất cả những điều này sẽ làm giảm khả năng bạn gặp phải vấn đề bảo mật từng chút một.
Ghi chú của biên tập viên:Bài đăng này ban đầu được xuất bản vào tháng 3 năm 2013 và đã được cập nhật để đảm bảo tính chính xác.