ฉันกำลังสร้าง API บนเว็บที่ปลอดภัยซึ่งใช้ HTTPS อย่างไรก็ตามหากฉันอนุญาตให้ผู้ใช้กำหนดค่า (รวมถึงการส่งรหัสผ่าน) โดยใช้สตริงการสืบค้นสิ่งนี้จะปลอดภัยหรือฉันควรบังคับให้ทำผ่าน POST หรือไม่
ฉันกำลังสร้าง API บนเว็บที่ปลอดภัยซึ่งใช้ HTTPS อย่างไรก็ตามหากฉันอนุญาตให้ผู้ใช้กำหนดค่า (รวมถึงการส่งรหัสผ่าน) โดยใช้สตริงการสืบค้นสิ่งนี้จะปลอดภัยหรือฉันควรบังคับให้ทำผ่าน POST หรือไม่
คำตอบ:
ใช่แล้ว. แต่การใช้ GET สำหรับข้อมูลที่สำคัญนั้นเป็นความคิดที่ไม่ดีด้วยเหตุผลหลายประการ:
ดังนั้นแม้ว่า Querystring จะปลอดภัย แต่ก็ไม่แนะนำให้ถ่ายโอนข้อมูลที่สำคัญผ่าน Querystring
[1] แม้ว่าฉันต้องทราบว่า RFC ระบุว่าเบราว์เซอร์ไม่ควรส่งผู้อ้างอิงจาก HTTPS ไปยัง HTTP แต่นั่นไม่ได้หมายความว่าแถบเครื่องมือเบราว์เซอร์ของบุคคลที่สามที่ไม่ดีหรือรูปภาพ / แฟลชภายนอกจากไซต์ HTTPS จะไม่รั่วไหล
History caches in browsersหรือเพิ่มการอ้างอิงสำหรับ ir ได้อย่างไร?
จากมุมมอง "sniff the network packet" การร้องขอ GET นั้นปลอดภัยเนื่องจากเบราว์เซอร์จะสร้างการเชื่อมต่อที่ปลอดภัยก่อนแล้วจึงส่งคำขอที่มีพารามิเตอร์ GET แต่ URL ของ GET จะถูกเก็บไว้ในประวัติเบราว์เซอร์ของผู้ใช้ / การเติมข้อความอัตโนมัติซึ่งไม่ใช่สถานที่ที่ดีในการจัดเก็บเช่นข้อมูลรหัสผ่านระบบนี้ใช้เฉพาะเมื่อคุณใช้คำจำกัดความ "Webservice" ที่กว้างขึ้นซึ่งอาจเข้าถึงบริการจากเบราว์เซอร์ หากคุณเข้าถึงจากแอปพลิเคชันที่กำหนดเองของคุณเท่านั้นนี่ไม่ควรเป็นปัญหา
ดังนั้นควรใช้การโพสต์อย่างน้อยสำหรับกล่องโต้ตอบรหัสผ่าน นอกจากนี้ตามที่ระบุไว้ในลิงค์ littlegeek ที่โพสต์ GET URL มีแนวโน้มที่จะถูกเขียนลงในบันทึกเซิร์ฟเวอร์ของคุณ
ใช่สตริงข้อความค้นหาของคุณจะถูกเข้ารหัส
เหตุผลเบื้องหลังคือสตริงการสืบค้นเป็นส่วนหนึ่งของโปรโตคอล HTTP ซึ่งเป็นโปรโตคอลชั้นแอปพลิเคชันในขณะที่ส่วนความปลอดภัย (SSL / TLS) มาจากชั้นการขนส่ง การเชื่อมต่อ SSL สร้างขึ้นก่อนจากนั้นพารามิเตอร์การสืบค้น (ซึ่งเป็นของโปรโตคอล HTTP) จะถูกส่งไปยังเซิร์ฟเวอร์
เมื่อสร้างการเชื่อมต่อ SSL ลูกค้าของคุณจะทำตามขั้นตอนต่อไปนี้ตามลำดับ สมมติว่าคุณพยายามเข้าสู่เว็บไซต์ที่ชื่อว่าexample.comและต้องการส่งข้อมูลรับรองของคุณโดยใช้พารามิเตอร์ข้อความค้นหา URL ที่สมบูรณ์ของคุณอาจมีลักษณะดังต่อไปนี้:
https://example.com/login?username=alice&password=12345)
example.comเป็นที่อยู่ IP (124.21.12.31)โดยใช้คำขอ DNS เมื่อทำการสืบค้นข้อมูลนั้นจะใช้เฉพาะข้อมูลโดเมนเท่านั้นคือexample.comจะใช้เท่านั้น124.21.12.31และจะพยายามเชื่อมต่อกับพอร์ต 443 (พอร์ตบริการ SSL ไม่ใช่พอร์ต HTTP เริ่มต้น 80)example.comจะส่งใบรับรองไปยังลูกค้าของคุณดังนั้นคุณจะไม่เปิดเผยข้อมูลที่ละเอียดอ่อน อย่างไรก็ตามการส่งข้อมูลรับรองของคุณผ่านเซสชัน HTTPS โดยใช้วิธีนี้ไม่ใช่วิธีที่ดีที่สุด คุณควรเลือกวิธีอื่น
(e.g http://example.com/login?username=alice&password=12345).
ใช่. ข้อความทั้งหมดของเซสชัน HTTPS นั้นปลอดภัยด้วย SSL ซึ่งรวมถึงแบบสอบถามและส่วนหัว ในแง่นั้น POST และ GET จะเหมือนกันทุกประการ
สำหรับความปลอดภัยของวิธีการของคุณไม่มีวิธีพูดจริงโดยไม่มีการตรวจสอบที่เหมาะสม
SSL เชื่อมต่อกับโฮสต์ก่อนดังนั้นชื่อโฮสต์และหมายเลขพอร์ตจะถูกถ่ายโอนเป็นข้อความธรรมดา เมื่อโฮสต์ตอบสนองและความท้าทายที่ประสบความสำเร็จลูกค้าจะเข้ารหัสคำขอ HTTP ด้วย URL จริง (คืออะไรหลังจากสแลชที่สาม) และส่งไปยังเซิร์ฟเวอร์
มีหลายวิธีในการทำลายความปลอดภัยนี้
เป็นไปได้ที่จะกำหนดค่าพร็อกซีเพื่อทำหน้าที่เป็น "คนที่อยู่ตรงกลาง" โดยทั่วไปเบราว์เซอร์จะส่งคำขอเชื่อมต่อกับเซิร์ฟเวอร์จริงไปยังพร็อกซี หากกำหนดค่าพร็อกซีด้วยวิธีนี้จะเชื่อมต่อผ่าน SSL กับเซิร์ฟเวอร์จริง แต่เบราว์เซอร์จะยังคงคุยกับพร็อกซี ดังนั้นหากผู้โจมตีสามารถเข้าถึงพร็อกซีได้เขาจะสามารถเห็นข้อมูลทั้งหมดที่ไหลผ่านพร็อกซีในรูปแบบข้อความที่ชัดเจน
คำขอของคุณจะปรากฏในประวัติเบราว์เซอร์ด้วย ผู้ใช้อาจถูกล่อลวงให้คั่นหน้าเว็บไซต์ ผู้ใช้บางคนมีการติดตั้งเครื่องมือทำบุ๊คมาร์คให้ตรงกันดังนั้นรหัสผ่านอาจสิ้นสุดที่ deli.ci.us หรือที่อื่น ๆ
ท้ายที่สุดบางคนอาจแฮ็คคอมพิวเตอร์ของคุณและติดตั้งเครื่องบันทึกแป้นพิมพ์หรือเครื่องขูดหน้าจอ (และไวรัสโทรจันประเภทอื่น ๆ ) เนื่องจากรหัสผ่านสามารถมองเห็นได้โดยตรงบนหน้าจอ (ตรงข้ามกับ "*" ในกล่องโต้ตอบรหัสผ่าน) นี่คือช่องโหว่ด้านความปลอดภัยอื่น
สรุป: เมื่อพูดถึงเรื่องความปลอดภัยต้องพึ่งพาเส้นทางที่ถูกตี มีมากเกินไปที่คุณไม่รู้ไม่คิดและจะทำลายคอของคุณ
ใช่ตราบใดที่ไม่มีใครมองไหล่ของคุณที่หน้าจอ
ผมไม่เห็นด้วยกับคำสั่งเกี่ยวกับ[ ... ] HTTP อ้างอิงการรั่วไหล (ภาพภายนอกในเพจเป้าหมายอาจรั่วไหลรหัสผ่าน)ในการตอบสนองของ Slough
HTTP 1.1 RFC ระบุอย่างชัดเจน :
ลูกค้าไม่ควรรวมเขตข้อมูลส่วนหัวของผู้อ้างอิงในคำขอ HTTP (ไม่ปลอดภัย) หากหน้าการอ้างอิงถูกถ่ายโอนด้วยโปรโตคอลที่ปลอดภัย
อย่างไรก็ตามบันทึกเซิร์ฟเวอร์และประวัติเบราว์เซอร์มีเหตุผลเพียงพอที่จะไม่นำข้อมูลที่สำคัญในสตริงการสืบค้น
ใช่ตั้งแต่วินาทีที่คุณสร้างการเชื่อมต่อ HTTPS ทุกครั้งจะปลอดภัย สตริงการสืบค้น (GET) ตามที่ POST ถูกส่งผ่าน SSL
คุณสามารถส่งรหัสผ่านเป็น MD5 hash param พร้อมเพิ่มเกลือบางส่วน เปรียบเทียบในฝั่งเซิร์ฟเวอร์สำหรับรับรองความถูกต้อง