GET หรือ POST ปลอดภัยกว่าอีกหรือไม่

เมื่อเปรียบเทียบ HTTP GET กับ HTTP POST ความแตกต่างจากมุมมองด้านความปลอดภัยคืออะไร ตัวเลือกหนึ่งมีความปลอดภัยมากกว่าตัวเลือกอื่นหรือไม่ ถ้าเป็นเช่นนั้นทำไม

ฉันรู้ว่า POST ไม่เปิดเผยข้อมูลเกี่ยวกับ URL แต่มีคุณค่าที่แท้จริงในนั้นหรือเป็นเพียงความปลอดภัยผ่านความสับสน? มีเหตุผลใดบ้างที่ฉันควรเลือก POST เมื่อคำนึงถึงความปลอดภัย?

แก้ไข:
HTTPS มีการเข้ารหัสข้อมูล POST แต่บุคคลที่สามสามารถดมกลิ่น URL ได้หรือไม่ นอกจากนี้ฉันกำลังติดต่อกับ JSP; เมื่อใช้ JSP หรือเฟรมเวิร์กที่คล้ายกันมันจะยุติธรรมหรือไม่ที่จะบอกว่าวิธีปฏิบัติที่ดีที่สุดคือการหลีกเลี่ยงการวางข้อมูลที่สำคัญใน POST หรือ GET ทั้งหมดและใช้โค้ดฝั่งเซิร์ฟเวอร์เพื่อจัดการข้อมูลที่ละเอียดอ่อนแทน?

เท่าที่ความปลอดภัยพวกเขาจะเหมือนกันโดยเนื้อแท้ แม้ว่าจะเป็นความจริงที่ POST ไม่เปิดเผยข้อมูลผ่าน URL แต่จะเปิดเผยข้อมูลเท่า GET ในการสื่อสารเครือข่ายระหว่างไคลเอนต์และเซิร์ฟเวอร์ หากคุณต้องการส่งผ่านข้อมูลที่มีความอ่อนไหวบรรทัดแรกของการป้องกันคือส่งผ่านโดยใช้ Secure HTTP

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

POST นั้นดีสำหรับแบบฟอร์มมาตรฐานที่ใช้ส่งข้อมูลครั้งเดียว ฉันจะไม่ใช้ GET สำหรับการโพสต์แบบฟอร์มจริงเว้นแต่อาจจะอยู่ในแบบฟอร์มการค้นหาที่คุณต้องการอนุญาตให้ผู้ใช้บันทึกแบบสอบถามในบุ๊กมาร์กหรืออะไรก็ตามที่อยู่ในบรรทัดเหล่านั้น

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

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

ค้นหาสไปเดอร์และส่วนช่วยดำเนินการของเว็บ

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

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

การโจมตีรองที่สับสน

รองผู้อำนวยการโจมตีสับสน (ที่รองผู้อำนวยการเป็นเบราว์เซอร์) เป็นไปได้ไม่ว่าคุณจะใช้ GET หรือ POST คำขอ

ในเว็บไซต์ที่ควบคุมโดยผู้โจมตี GET และ POST นั้นง่ายต่อการส่ง โดยที่ผู้ใช้ไม่ต้องทำอะไรเลย

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

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

พร็อกซีบันทึก

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

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

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

แคชพร็อกซี

การแคชพร็อกซีอาจเก็บการตอบสนองของ GET แต่ไม่ใช่การตอบกลับ POST ต้องบอกว่าการตอบสนองของ GET นั้นไม่สามารถทำแคชได้โดยใช้ความพยายามน้อยกว่าการแปลง URL เป็นตัวจัดการ POST

HTTP "ผู้อ้างอิง"

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

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

ประวัติเบราว์เซอร์

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

การดำเนินการรีเฟรชเบราว์เซอร์

เบราว์เซอร์จะลองคำขอ GET อีกครั้งทันทีที่ผู้ใช้กด "รีเฟรช" อาจทำเช่นนั้นเมื่อกู้คืนแท็บหลังจากปิดเครื่อง การกระทำใด ๆ (เช่นการชำระเงิน) จะถูกทำซ้ำโดยไม่มีการเตือนล่วงหน้า

เบราว์เซอร์จะไม่ลองคำขอ POST อีกครั้งโดยไม่มีคำเตือน

นี่เป็นเหตุผลที่ดีที่จะใช้เฉพาะคำขอ POST สำหรับการเปลี่ยนแปลงข้อมูล แต่ไม่มีอะไรเกี่ยวข้องกับพฤติกรรมที่เป็นอันตรายและดังนั้นความปลอดภัย

แล้วฉันควรทำอย่างไรดี?

• ใช้เฉพาะคำขอ POST เพื่อเปลี่ยนข้อมูลส่วนใหญ่เป็นเหตุผลที่ไม่เกี่ยวข้องกับความปลอดภัย
• ใช้คำขอ POST สำหรับแบบฟอร์มเข้าสู่ระบบเท่านั้น ทำอย่างอื่นแนะนำเวกเตอร์โจมตี
• หากไซต์ของคุณดำเนินงานที่ละเอียดอ่อนคุณต้องการใครสักคนที่รู้ว่าพวกเขากำลังทำอะไรเพราะไม่สามารถครอบคลุมได้ในคำตอบเดียว คุณต้องใช้ HTTPS, HSTS, CSP, ลดการฉีด SQL, การฉีดสคริปต์ (XSS) , CSRFและสิ่งอื่น ๆ อีกมากมายที่อาจเฉพาะเจาะจงกับแพลตฟอร์มของคุณ (เช่นช่องโหว่การมอบหมายจำนวนมากในกรอบต่าง ๆ : ASP.NET MVC , Ruby on Railsเป็นต้น) ไม่มีสิ่งเดียวที่จะสร้างความแตกต่างระหว่าง "ความปลอดภัย" (ไม่ใช้ประโยชน์ได้) และ "ไม่ปลอดภัย"

ใน HTTPS ข้อมูล POST จะถูกเข้ารหัส แต่บุคคลที่สามสามารถดมกลิ่น URL ได้หรือไม่?

ไม่พวกเขาไม่สามารถดมกลิ่นได้ แต่ URL จะถูกเก็บไว้ในประวัติเบราว์เซอร์

มันจะยุติธรรมหรือไม่ที่จะบอกว่าวิธีปฏิบัติที่ดีที่สุดคือหลีกเลี่ยงการวางข้อมูลที่สำคัญใน POST หรือ GET ไว้ด้วยกันและใช้รหัสฝั่งเซิร์ฟเวอร์เพื่อจัดการข้อมูลที่ละเอียดอ่อนแทน?

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

คุณไม่มีการรักษาความปลอดภัยที่ดีกว่าเนื่องจากตัวแปรถูกส่งผ่าน HTTP POST มากกว่าที่คุณมีกับตัวแปรที่ส่งผ่าน HTTP GET

HTTP / 1.1 ให้วิธีการมากมายแก่เราในการส่งคำขอ :

• ตัวเลือก
• GET
• ศีรษะ
• โพสต์
• PUT
• ลบ
• ติดตาม
• CONNECT

สมมติว่าคุณมีเอกสาร HTML ต่อไปนี้โดยใช้ GET:

<html>
<body>
<form action="http://example.com" method="get">
    User: <input type="text" name="username" /><br/>
    Password: <input type="password" name="password" /><br/>
    <input type="hidden" name="extra" value="lolcatz" />
    <input type="submit"/>
</form>
</body>
</html>

เบราว์เซอร์ของคุณถามอะไร มันถามสิ่งนี้:

 GET /?username=swordfish&password=hunter2&extra=lolcatz HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

ทีนี้ลองทำเป็นว่าเราเปลี่ยนวิธีการร้องขอนั้นเป็น POST:

 POST / HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Content-Length: 49
 Cache-Control: max-age=0
 Origin: null
 Content-Type: application/x-www-form-urlencoded
 Accept: application/xml,application/xhtml+xml,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

 username=swordfish&password=hunter2&extra=lolcatz

ทั้งคำขอ HTTP เหล่านี้คือ:

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

เบราว์เซอร์จำนวนมากไม่รองรับวิธี HTTP อื่น ๆ นอกเหนือจาก POST / GET

พฤติกรรมของเบราว์เซอร์จำนวนมากเก็บที่อยู่ของหน้า แต่นี่ไม่ได้หมายความว่าคุณสามารถเพิกเฉยต่อปัญหาอื่น ๆ ได้

ดังนั้นจะเฉพาะเจาะจง:

มีความปลอดภัยมากกว่าหรือไม่? ฉันรู้ว่า POST ไม่เปิดเผยข้อมูลเกี่ยวกับ URL แต่มีคุณค่าที่แท้จริงในนั้นหรือเป็นเพียงความปลอดภัยผ่านความสับสน? การปฏิบัติที่ดีที่สุดที่นี่คืออะไร?

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

มีการเข้ารหัสข้อมูล POST ผ่าน https แต่ URL อาจถูกดมกลิ่นโดยบุคคลที่สามหรือไม่

นี่คือวิธีการทำงานของ SSL จำคำขอทั้งสองที่ฉันส่งไปด้านบนได้ไหม นี่คือลักษณะที่ปรากฏใน SSL: (ฉันเปลี่ยนหน้าเป็นhttps://encrypted.google.com/เนื่องจาก example.com ไม่ตอบสนองกับ SSL)

POST ผ่าน SSL

q5XQP%RWCd2u#o/T9oiOyR2_YO?yo/3#tR_G7 2_RO8w?FoaObi)
oXpB_y?oO4q?`2o?O4G5D12Aovo?C@?/P/oOEQC5v?vai /%0Odo
QVw#6eoGXBF_o?/u0_F!_1a0A?Q b%TFyS@Or1SR/O/o/_@5o&_o
9q1/?q$7yOAXOD5sc$H`BECo1w/`4?)f!%geOOF/!/#Of_f&AEI#
yvv/wu_b5?/o d9O?VOVOFHwRO/pO/OSv_/8/9o6b0FGOH61O?ti
/i7b?!_o8u%RS/Doai%/Be/d4$0sv_%YD2_/EOAO/C?vv/%X!T?R
_o_2yoBP)orw7H_yQsXOhoVUo49itare#cA?/c)I7R?YCsg ??c'
(_!(0u)o4eIis/S8Oo8_BDueC?1uUO%ooOI_o8WaoO/ x?B?oO@&
Pw?os9Od!c?/$3bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR'u/
T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r

รับผ่าน SSL

rV/O8ow1pc`?058/8OS_Qy/$7oSsU'qoo#vCbOO`vt?yFo_?EYif)
43`I/WOP_8oH0%3OqP_h/cBO&24?'?o_4`scooPSOVWYSV?H?pV!i
?78cU!_b5h'/b2coWD?/43Tu?153pI/9?R8!_Od"(//O_a#t8x?__
bb3D?05Dh/PrS6_/&5p@V f $)/xvxfgO'q@y&e&S0rB3D/Y_/fO?
_'woRbOV?_!yxSOdwo1G1?8d_p?4fo81VS3sAOvO/Db/br)f4fOxt
_Qs3EO/?2O/TOo_8p82FOt/hO?X_P3o"OVQO_?Ww_dr"'DxHwo//P
oEfGtt/_o)5RgoGqui&AXEq/oXv&//?%/6_?/x_OTgOEE%v (u(?/
t7DX1O8oD?fVObiooi'8)so?o??`o"FyVOByY_ Supo? /'i?Oi"4
tr'9/o_7too7q?c2Pv

(หมายเหตุ: ฉันแปลง HEX เป็น ASCII บางส่วนไม่ควรแสดงให้เห็นได้ชัด)

การสนทนา HTTP ทั้งหมดถูกเข้ารหัสส่วนการสื่อสารที่มองเห็นได้เท่านั้นอยู่ในเลเยอร์ TCP / IP (หมายถึงที่อยู่ IP และข้อมูลพอร์ตการเชื่อมต่อ)

ขอผมสร้างประโยคที่ยิ่งใหญ่ที่นี่ เว็บไซต์ของคุณไม่ได้รับการรักษาความปลอดภัยที่ดีกว่าหนึ่งวิธี HTTP มากกว่าวิธีอื่นแฮ็กเกอร์และ newbs ทั่วโลกรู้วิธีการทำสิ่งที่ฉันเพิ่งแสดงที่นี่ หากคุณต้องการความปลอดภัยให้ใช้ SSL เบราว์เซอร์มักจะเก็บประวัติขอแนะนำโดย RFC2616 9.1.1 ว่าอย่าใช้ GET เพื่อดำเนินการ แต่คิดว่า POST มีความปลอดภัยผิดปกติ

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

เพื่อแสดงให้เห็นถึงสาเหตุที่ POST ไม่ปลอดภัย Facebook ใช้คำขอ POST ทั่วสถานที่ดังนั้นซอฟต์แวร์เช่นFireSheep จึงมีอยู่ได้อย่างไร

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

ไม่มีความปลอดภัยเพิ่มเติม

ข้อมูลการโพสต์ไม่ปรากฏในประวัติและ / หรือไฟล์บันทึก แต่ถ้าข้อมูลควรได้รับการรักษาความปลอดภัยคุณต้องใช้ SSL
มิฉะนั้นใครก็ตามที่ดมสายสามารถอ่านข้อมูลของคุณได้

แม้ว่าPOSTจะไม่ได้รับประโยชน์ด้านความปลอดภัยที่แท้จริงเมื่อเทียบกับGETแบบฟอร์มการเข้าสู่ระบบหรือรูปแบบอื่นใดที่มีข้อมูลที่ค่อนข้างละเอียดอ่อนตรวจสอบให้แน่ใจว่าคุณใช้POSTเป็น:

1. ข้อมูลPOSTed จะไม่ถูกบันทึกในประวัติผู้ใช้
2. ข้อมูลที่ละเอียดอ่อน (รหัสผ่าน ฯลฯ ) ที่ส่งในแบบฟอร์มจะไม่สามารถมองเห็นได้ในภายหลังในแถบ URL (โดยใช้GETมันจะสามารถมองเห็นได้ในประวัติและแถบ URL)

นอกจากนี้ยังGETมีข้อ จำกัด ทางทฤษฎีของข้อมูล POSTไม่

สำหรับข้อมูลที่ละเอียดอ่อนจริงตรวจสอบให้แน่ใจว่าได้ใช้SSL( HTTPS)

หนึ่งใน GET และ POST นั้นมีความ "ปลอดภัยมากกว่า" โดยธรรมชาติเช่นเดียวกับแฟกซ์และโทรศัพท์ที่ไม่มี "ปลอดภัยกว่า" กว่าอีกอันหนึ่ง มีการจัดเตรียมวิธีการ HTTP หลากหลายวิธีเพื่อให้คุณสามารถเลือกวิธีที่เหมาะสมที่สุดสำหรับปัญหาที่คุณพยายามแก้ไข GET นั้นเหมาะสำหรับคิวรีแบบ idempotent มากกว่าในขณะที่ POST นั้นเหมาะสำหรับคิวรี "action" แต่คุณสามารถยิงด้วยตนเองได้อย่างง่ายดายถ้าคุณไม่เข้าใจสถาปัตยกรรมความปลอดภัยสำหรับแอปพลิเคชันที่คุณกำลังบำรุงรักษา

อาจเป็นวิธีที่ดีที่สุดถ้าคุณอ่านบทที่ 9: นิยามวิธีการของHTTP / 1.1 RFCเพื่อให้ได้ภาพรวมของสิ่งที่ GET และ POST ได้รับการคาดหมายมาตั้งแต่แรก

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

ผู้รับมอบฉันทะที่ดีจะไม่แคชข้อมูล POST แต่พวกเขาอาจแคชข้อมูล GET จาก URL ดังนั้นคุณอาจกล่าวได้ว่า POST น่าจะปลอดภัยกว่า แต่ข้อมูล POST จะยังคงมีให้สำหรับผู้รับมอบฉันทะที่ไม่ได้เล่นอย่างสวยงาม

ดังที่ได้กล่าวไว้ในคำตอบหลายคำตอบการเดิมพันเพียงอย่างเดียวคือผ่าน SSL

แต่ให้แน่ใจว่าวิธีการ GET ไม่ส่งการเปลี่ยนแปลงใด ๆ เช่นการลบแถวฐานข้อมูลเป็นต้น

วิธีการตามปกติของฉันในการเลือกมีดังนี้:

• GETสำหรับรายการที่จะถูกดึงมาในภายหลังโดย URL
  • เช่นการค้นหาควรเป็น GET เพื่อให้คุณสามารถทำ search.php? s = XXX ได้ในภายหลัง
• โพสต์สำหรับรายการที่จะถูกส่ง
  • นี่คือค่อนข้างที่มองไม่เห็น comapred จะได้รับและยากที่จะส่ง แต่ข้อมูลยังสามารถส่งผ่านทางโค้ง

นี้ไม่ได้เกี่ยวข้องกับการรักษาความปลอดภัย แต่ ... เบราว์เซอร์ไม่แคช POST การร้องขอ

ไม่มีใครยืนยันความปลอดภัยอย่างน่าอัศจรรย์ แต่ GET บอกถึงผลข้างเคียงบางอย่างที่โดยทั่วไปป้องกันไม่ให้ปลอดภัย

GET URL แสดงในประวัติเบราว์เซอร์และบันทึกของเว็บเซิร์ฟเวอร์ ด้วยเหตุผลนี้จึงไม่ควรใช้สิ่งเหล่านี้เช่นแบบฟอร์มเข้าสู่ระบบและหมายเลขบัตรเครดิต

อย่างไรก็ตามเพียงโพสต์ข้อมูลที่ไม่ปลอดภัย เพื่อที่คุณต้องการ SSL ทั้ง GET และ POST ส่งข้อมูลแบบธรรมดาผ่านสายสัญญาณเมื่อใช้กับ HTTP

มีเหตุผลที่ดีอื่น ๆ สำหรับข้อมูล POST เช่นกันเช่นความสามารถในการส่งข้อมูลไม่ จำกัด จำนวนหรือซ่อนพารามิเตอร์จากผู้ใช้ทั่วไป

ข้อเสียคือผู้ใช้ไม่สามารถคั่นหน้าผลลัพธ์การสืบค้นที่ส่งผ่าน POST เพื่อที่คุณจะต้องได้รับ

พิจารณาสถานการณ์นี้: API เลอะเทอะยอมรับคำขอ GET เช่น:

http://www.example.com/api?apikey=abcdef123456&action=deleteCategory&id=1

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

น่าเสียดายที่ API ของจริงทำงานด้วยวิธีนี้

ฉันไม่ชอบความคิดในการมีข้อมูลที่ละเอียดอ่อนบางอย่างในบันทึกหรือแสดงในเบราว์เซอร์ POST และ GET ไม่เหมือนกัน ใช้แต่ละอันตามความเหมาะสม

1. ความปลอดภัยของข้อมูลในการขนส่ง: ไม่มีความแตกต่างระหว่าง POST และ GET

2. ความปลอดภัยของข้อมูลในคอมพิวเตอร์ความปลอดภัย: POST ปลอดภัยกว่า (ไม่มีประวัติ URL)

แนวคิดเรื่องความปลอดภัยนั้นไม่มีความหมายหากคุณไม่ได้กำหนดสิ่งที่ปลอดภัย

หากคุณต้องการความปลอดภัยจากประวัติเบราว์เซอร์ที่เก็บไว้การบันทึกบางประเภทและผู้ที่ดู URL ของคุณ POST จะปลอดภัยกว่า

หากคุณต้องการความปลอดภัยจากใครบางคนที่ดมกลิ่นกิจกรรมเครือข่ายของคุณนั่นก็ไม่ต่างอะไร

หลายคนยอมรับการประชุม (พาดพิงถึงโดย Ross) ที่ GET ร้องขอการดึงข้อมูลเท่านั้นและไม่แก้ไขข้อมูลใด ๆ บนเซิร์ฟเวอร์และคำขอ POST จะใช้สำหรับการปรับเปลี่ยนข้อมูลทั้งหมด แม้ว่าจะไม่ปลอดภัยกว่าอีกข้อหนึ่ง แต่ถ้าคุณทำตามอนุสัญญานี้คุณสามารถใช้ตรรกะความปลอดภัยแบบตัดขวาง (เช่นผู้ที่มีบัญชีเท่านั้นที่สามารถแก้ไขข้อมูลได้ดังนั้นโพสต์ที่ไม่ผ่านการตรวจสอบความถูกต้อง)

เป็นการยากที่จะแก้ไขคำขอ POST (ต้องใช้ความพยายามมากกว่าการแก้ไขสตริงแบบสอบถาม) แก้ไข:ในคำอื่น ๆ มันเป็นเพียงการรักษาความปลอดภัยด้วยความสับสนและแทบจะไม่

ฉันไม่ได้กำลังจะทำซ้ำคำตอบอื่น ๆ ทั้งหมด แต่มีแง่มุมหนึ่งที่ฉันยังไม่ได้เห็นกล่าวถึง - มันเป็นเรื่องราวของการหายไปของข้อมูล ฉันไม่รู้จะหาที่ไหน แต่ ...

โดยพื้นฐานแล้วมันเกี่ยวกับเว็บแอปพลิเคชั่นที่ลึกลับทุกสองสามคืนทำให้ข้อมูลทั้งหมดหลวมและไม่มีใครรู้ว่าทำไม การตรวจสอบบันทึกในภายหลังพบว่าเว็บไซต์นั้นถูกค้นพบโดย google หรือเดอร์ตัวอื่นโดยพลการซึ่ง GET (อ่าน: GOT) ได้รับการเชื่อมโยงทั้งหมดที่พบในเว็บไซต์ - รวมทั้ง "ลบรายการนี้" และ "คุณแน่ใจหรือไม่?" การเชื่อมโยง

ที่จริงแล้ว - บางส่วนถูกกล่าวถึง นี่คือเรื่องราวเบื้องหลัง "ไม่เปลี่ยนข้อมูลใน GET แต่ใช้เฉพาะกับ POST" โปรแกรมรวบรวมข้อมูลจะติดตาม GET อย่างมีความสุขไม่โพสต์ แม้ robots.txt ก็ไม่ได้ช่วยป้องกันโปรแกรมรวบรวมข้อมูลที่ทำงานผิดพลาด

คุณควรทราบด้วยว่าหากเว็บไซต์ของคุณมีลิงค์ไปยังเว็บไซต์ภายนอกอื่น ๆ ที่คุณไม่ได้ควบคุมโดยใช้ GET จะใส่ข้อมูลนั้นไว้ในส่วนหัว refeerer ในเว็บไซต์ภายนอกเมื่อพวกเขากดลิงก์ในเว็บไซต์ของคุณ ดังนั้นการถ่ายโอนข้อมูลเข้าสู่ระบบผ่านวิธีการ GET จึงเป็นปัญหาใหญ่อยู่เสมอ เนื่องจากอาจเปิดเผยข้อมูลการเข้าสู่ระบบเพื่อให้เข้าถึงได้ง่ายเพียงตรวจสอบบันทึกหรือดูใน Google Analytics (หรือคล้ายกัน)

RFC7231:

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

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

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

ตามที่ก่อนหน้านี้บางคนบอกว่า HTTPS นำมาซึ่งความปลอดภัย

อย่างไรก็ตาม POST นั้นปลอดภัยกว่า GET เล็กน้อยเนื่องจาก GET สามารถเก็บไว้ในประวัติศาสตร์ได้

แต่ยิ่งกว่านั้นน่าเศร้าที่บางครั้งการเลือกตั้ง POST หรือ GET ไม่ได้ขึ้นอยู่กับนักพัฒนา ตัวอย่างเช่นการเชื่อมโยงหลายมิติจะถูกส่งโดย GET เสมอ (เว้นแต่จะเปลี่ยนเป็นรูปแบบโพสต์โดยใช้จาวาสคริปต์)

GET สามารถมองเห็นได้ทุกคน (แม้จะอยู่บนไหล่ของคุณตอนนี้) และถูกบันทึกไว้ในแคชดังนั้นจึงปลอดภัยน้อยกว่าในการใช้โพสต์ btw โพสต์โดยไม่มีรูทีนการเข้ารหัสลับบางอย่างไม่แน่ใจสำหรับความปลอดภัยเล็กน้อยที่คุณใช้ SSL https)

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

POSTเป็นสิ่งที่ตรงกันข้ามมันเกือบจะไม่ได้เข้าสู่ระบบในระดับสากลซึ่งนำไปสู่กิจกรรมการโจมตีที่ยากมาก

ฉันไม่ซื้ออาร์กิวเมนต์ "มันใหญ่เกินไป" นั่นคือเหตุผลที่ไม่มีการบันทึกอะไรอย่างน้อย 1KB จะไปไกลสำหรับคนที่จะระบุว่าผู้โจมตีทำงานอยู่ที่จุดเริ่มต้นที่อ่อนแอจนกว่า POST จะทำเช่นนั้น dis-service สองเท่าโดยการเปิดใช้งาน HTTP ประตูหลังเพื่อส่งผ่านข้อมูลจำนวนไม่ จำกัด

ความแตกต่างคือ GET ส่งข้อมูลเปิดและซ่อน POST (ใน http-header)

ดังนั้นการได้รับจะดีกว่าสำหรับข้อมูลที่ไม่ปลอดภัยเช่นสตริงการสืบค้นใน Google Auth-data จะไม่ถูกส่งผ่าน GET - ดังนั้นให้ใช้ POST ที่นี่ แน่นอนว่าธีมทั้งหมดนั้นซับซ้อนกว่าเล็กน้อย หากคุณต้องการอ่านเพิ่มเติมอ่านบทความนี้ (ภาษาเยอรมัน)

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

มีโหมดที่การร้องขอ GET ยังมีช่องโหว่ SPDY บีบอัดส่วนหัวคำขอ TLS ยังมีการบีบอัดทางเลือก (ไม่ค่อยได้ใช้) ในสถานการณ์เหล่านี้การโจมตีจะง่ายต่อการป้องกัน (ผู้ขายเบราว์เซอร์ที่ให้การแก้ไขแล้ว) การบีบอัดระดับ HTTP เป็นคุณสมบัติพื้นฐานที่ไม่น่าเป็นไปได้ที่ผู้ขายจะปิดการใช้งาน

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

ข้อจำกัดความรับผิดชอบ: คะแนนต่อไปนี้ใช้สำหรับการเรียก API เท่านั้นไม่ใช่ URL ของเว็บไซต์

ความปลอดภัยบนเครือข่าย : คุณต้องใช้ HTTPS GET และ POST มีความปลอดภัยเท่ากันในกรณีนี้

ประวัติเบราว์เซอร์ : สำหรับแอปพลิเคชันส่วนหน้าเช่น Angular JS, React JS และอื่น ๆ การเรียก API คือการโทร AJAX ที่ทำโดย front-end สิ่งเหล่านี้ไม่ได้เป็นส่วนหนึ่งของประวัติเบราว์เซอร์ ดังนั้น POST และ GET จึงมีความปลอดภัยเท่าเทียมกัน

ล็อกฝั่งเซิร์ฟเวอร์ : ด้วยการใช้ชุดการเขียนของการปิดบังข้อมูลและรูปแบบการเข้าถึงบันทึกเป็นไปได้ที่จะซ่อนข้อมูลที่สำคัญทั้งหมดหรือเฉพาะจาก request-URL

การเปิดเผยข้อมูลในคอนโซลของเบราว์เซอร์:สำหรับผู้ที่มีเจตนาร้ายมันเกือบจะเป็นความพยายามเดียวกันในการดูข้อมูล POST มากเท่ากับ GET

ดังนั้นด้วยวิธีการบันทึกที่ถูกต้อง GET API จึงมีความปลอดภัยเท่ากับ POST API การติดตาม POST ทุกหนทุกแห่งบังคับให้คำจำกัดความ API แย่และควรหลีกเลี่ยง

โพสต์มีความปลอดภัยมากที่สุดพร้อมกับติดตั้ง SSL เพราะมันส่งในส่วนเนื้อหา

แต่วิธีการทั้งหมดนี้ไม่ปลอดภัยเพราะโปรโตคอล 7 บิตที่ใช้ภายใต้มันสามารถแฮ็กที่มีการหลบหนี แม้ผ่านไฟร์วอลล์เว็บแอพพลิเคชันระดับ 4

ซ็อกเก็ตไม่รับประกันเช่นกัน ... แม้ว่ามันจะปลอดภัยกว่าในบางวิธี

นี่เป็นโพสต์เก่า แต่ฉันต้องการคัดค้านคำตอบบางส่วน หากคุณกำลังถ่ายโอนข้อมูลที่สำคัญคุณจะต้องใช้ SSL หากคุณใช้ SSL กับพารามิเตอร์ GET (เช่น? userid = 123) ข้อมูลนั้นจะถูกส่งเป็นข้อความธรรมดา! หากคุณส่งโดยใช้ POST ค่าจะถูกใส่ไว้ในเนื้อความที่เข้ารหัสของข้อความและดังนั้นจึงไม่สามารถอ่านการโจมตี MITM ส่วนใหญ่ได้

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

ในระยะสั้นคุณสามารถส่งข้อมูลอย่างปลอดภัยใน POST ผ่าน SSL แต่คุณไม่สามารถทำได้ด้วย GET โดยใช้ SSL หรือไม่

แม้แต่ POST ก็รับคำขอได้ สมมติว่าคุณมีฟอร์มที่มีอินพุตเช่น user.name และ user.passwd ซึ่งควรจะสนับสนุนชื่อผู้ใช้และรหัสผ่าน หากเราเพียงแค่เพิ่ม? user.name = "ผู้ใช้ของฉัน & user.passwd =" รหัสผ่านของฉัน "การร้องขอจะได้รับการยอมรับโดย" บายพาสหน้าเข้าสู่ระบบ "

ทางออกสำหรับสิ่งนี้คือการนำตัวกรอง (ตัวกรอง java เป็น e) ไปใช้บนฝั่งเซิร์ฟเวอร์และตรวจสอบว่าไม่มีการส่งคำสั่งสตริงเป็นอาร์กิวเมนต์ GET