Cách nhập các bài gửi từ biểu mẫu công khai vào mạng riêng
Theo dõi một bài gửi từ biểu mẫu công khai từ bản ghi tiếp nhận đến trình nhập riêng, và giữ việc kiểm tra, thông tin xác thực và xử lý thử lại ở đúng phía.
Một biểu mẫu công khai không bao giờ nói chuyện với mạng riêng vẫn tạo ra dữ liệu mà mạng riêng phải đánh giá. Đường hầm chỉ thay đổi ai gọi ai. Mọi thứ sau khi tải xuống là một quyết định nhập và nó thuộc về phía riêng. Hướng dẫn này theo dõi một bài gửi từ trình duyệt đến một bản ghi nội bộ đã được ghi nhận.
Bắt đầu từ nơi bài gửi đến
Trình duyệt gửi đến một điểm cuối công khai, điểm này ghi một hàng vào kho tiếp nhận được kiểm soát và không trả về gì ngoài một xác nhận. Kho đó là điểm bàn giao và nó phải là thứ duy nhất mà tầng công khai có thể ghi vào. Giữ nguyên dữ liệu thô ở đó, cùng với thời điểm nó đến và một mã định danh bản ghi ổn định.
Sau đó một nhân viên riêng kéo các hàng đang chờ qua đường hầm và quyết định làm gì với từng hàng. Nó chạy dưới danh tính riêng của mình, và đó là chủ đề của phần tiếp theo.
curl --silent --fail \
--cert /etc/importer/client.crt --key /etc/importer/client.key \
"https://intake.corp.internal/api/pending?limit=20" \
-o /var/lib/importer/pending.json
Chỉ trao cho trình nhập quyền hạn cần thiết
Tiến trình web công khai và danh tính ghi vào ứng dụng nội bộ phải là hai chủ thể khác nhau. Một máy chủ công khai không cần quyền quản trị nội bộ chỉ vì nó phải chuyển dữ liệu biểu mẫu, và một tài khoản dùng chung cho cả hai phía biến mọi lỗi web thành một lần ghi nội bộ. Cấp cho nhân viên thông tin xác thực riêng, giới hạn nó trong một thao tác nhập duy nhất và ghi lại chủ thể nào đã thực hiện mỗi lần nhập. Chính sự tách biệt đó làm cho ranh giới đường hầm có ý nghĩa thay vì chỉ để trang trí.
Cũng hãy giới hạn nguồn mà nhân viên được đọc. Nếu việc triển khai dùng hàng đợi hoặc dịch vụ chuyển giao, dịch vụ đó giữ xác thực và chính sách truy cập riêng của nó, vì VPN không xác thực bất cứ thứ gì bên trong dữ liệu.
Một hàm ngắn hạn cũng không được miễn trừ khỏi cùng một lần xem xét. Trong khi nó chạy, vị trí mạng và thông tin xác thực của nó vẫn cấp quyền, và thời gian sống ngắn hơn chỉ thu hẹp cửa sổ. Thời gian sống không thay thế cho việc quyết định danh tính được thực hiện những thao tác nào.
Kiểm tra trước khi bất cứ điều gì nội bộ thay đổi
Các trường của biểu mẫu công khai là văn bản do kẻ tấn công kiểm soát cho đến khi được chứng minh ngược lại, và hướng dẫn của OWASP về kiểm tra đầu vào xếp các luồng phía máy chủ vào nguồn không đáng tin cậy chính vì lý do đó. Một đường truyền được mã hóa nói rằng các byte đã đến nguyên vẹn, không phải rằng chúng mô tả một yêu cầu được phép. Phân tích và kiểm tra trước mọi bước có đặc quyền, để một hàng xấu không bao giờ đến được đường mã có thể hành động.
Xác định các trường được phép, định dạng, kích thước của chúng và các quy tắc nghiệp vụ phải được thỏa mãn. Một ngày có thể đúng định dạng mà vẫn sai cho thao tác được yêu cầu, và một dữ liệu nêu tên tài khoản nội bộ hoặc trạng thái phê duyệt không được phép tự cấp cho mình bất kỳ thứ nào trong hai thứ đó.
Gửi các hàng bị từ chối đến một kết quả xem xét thay vì đoán một bản sửa hoặc chuyển chúng đến một shell hay giao diện cơ sở dữ liệu thô. Ghi lại mã định danh bản ghi và quy tắc đã thất bại, không phải mọi trường mà người nộp đã nhập.
Tạo điểm thử lại tại một thao tác
Nếu bản ghi submission-1042 được kéo hai lần vì xác nhận đầu tiên bị mất, nhân viên cần một cách bền vững để nhận ra bản ghi nguồn và kết quả đã ghi nhận của nó. Một lịch chạy công việc một lần không chứng minh rằng mỗi hàng đã được áp dụng một lần. Việc gửi trùng lặp là bình thường, nên thiết kế phải hấp thụ nó.
Dùng giao dịch và cơ chế xử lý trùng lặp của chính ứng dụng nội bộ, và giữ mã định danh nguồn, kết quả và xác nhận trong một chuỗi nhất quán. Chỉ xác nhận sau khi thao tác dự định đã được ghi nhận hoặc gán bền vững, và không bao giờ xóa hàng tiếp nhận chỉ vì các byte đã được tải xuống.
Sau đó chứng minh điều đó bằng ba bộ dữ liệu cố định: một hàng hợp lệ, một hàng sai định dạng và cùng mã định danh nguồn được kiểm soát đó được gửi hai lần. Mỗi bộ đều đi qua cùng điểm cuối mà nhân viên sử dụng.
for f in fixtures/valid-submission.json fixtures/bad-date.json; do
curl --silent --fail --cert /etc/importer/client.crt \
-X POST --data @"$f" https://intake.corp.internal/api/records
done
curl --silent --fail --cert /etc/importer/client.crt \
-X POST --data @fixtures/valid-submission.json https://intake.corp.internal/api/records
Hai hàng đầu tiên phải kết thúc ở các trạng thái nội bộ khác nhau, và hàng thứ ba phải trả về mã định danh đã được ghi nhận cho bản ghi nguồn đó thay vì tạo ra cái thứ hai. Bất kỳ điều gì khác nghĩa là việc nhập vẫn chưa thể lặp lại.