วิธีนำเข้าการส่งแบบฟอร์มสาธารณะเข้าสู่เครือข่ายส่วนตัว

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

เริ่มจากจุดที่การส่งมาถึง

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

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

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

ให้อำนาจแก่ตัวนำเข้าเท่าที่จำเป็น

กระบวนการเว็บสาธารณะและตัวตนที่เขียนลงในแอปพลิเคชันภายในควรเป็นสองตัวหลักที่แตกต่างกัน เซิร์ฟเวอร์สาธารณะไม่จำเป็นต้องมีการบริหารจัดการภายในเพียงเพราะต้องส่งข้อมูลแบบฟอร์ม และบัญชีร่วมบัญชีเดียวสำหรับทั้งสองฝั่งจะเปลี่ยนข้อบกพร่องของเว็บใดๆ ให้เป็นการเขียนภายใน ออกข้อมูลรับรองให้ผู้ปฏิบัติงานเอง จำกัดให้อยู่ใน операцииนำเข้าหนึ่งครั้ง และบันทึกว่าตัวหลักใดดำเนินการนำเข้าแต่ละครั้ง การแยกนั้นเองที่ทำให้ขอบเขตอุโมงค์มีความหมายแทนที่จะเป็นเพียงการตกแต่ง

จำกัดด้วยว่าผู้ปฏิบัติงานอ่านจากแหล่งใดได้ หากการใช้งานใช้คิวหรือบริการถ่ายโอน บริการนั้นจะรักษาการพิสูจน์ตัวตนและนโยบายการเข้าถึงของตัวเอง เพราะ VPN ไม่ได้พิสูจน์ตัวตนสิ่งใดภายในเพย์โหลด

ฟังก์ชันอายุสั้นไม่ได้รับการยกเว้นจากการตรวจทานเดียวกัน ขณะทำงาน ตำแหน่งเครือข่ายและข้อมูลรับรองยังคงให้อำนาจ และอายุที่สั้นลงเพียงทำให้หน้าต่างแคบลง อายุไม่ใช่สิ่งทดแทนการตัดสินใจว่าตัวตนทำ операцииใดได้

ตรวจสอบก่อนที่สิ่งใดภายในจะเปลี่ยน

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

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

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

สร้างจุดลองใหม่ที่การดำเนินการเดียว

หากบันทึก submission-1042 ถูกดึงสองครั้งเพราะการยืนยันครั้งแรกหายไป ผู้ปฏิบัติงานต้องมีวิธีที่คงทนในการจดจำบันทึกต้นทางและผลลัพธ์ที่ยืนยันแล้ว ตารางเวลาที่รันงานครั้งเดียวไม่ได้ยืนยันว่าแต่ละแถวถูกใช้หนึ่งครั้ง การส่งซ้ำเป็นเรื่องปกติ ดังนั้นการออกแบบต้องรองรับ

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

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

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

สองแถวแรกต้องจบในสถานะภายในที่ต่างกัน และแถวที่สามต้องคืนตัวระบุที่บันทึกไว้แล้วสำหรับบันทึกต้นทางนั้นแทนการสร้างอันที่สอง สิ่งอื่นใดหมายความว่าการนำเข้ายังทำซ้ำไม่ได้