แบบฟอร์มเข้าสู่ระบบจำเป็นต้องมีโทเค็นต่อต้านการโจมตี CSRF หรือไม่

161

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

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

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

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

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

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

ความเข้าใจของฉันเกี่ยวกับการโจมตีและโทเค็น CSRF ถูกต้องหรือไม่ และพวกเขาไม่มีประโยชน์อะไรสำหรับแบบฟอร์มการเข้าสู่ระบบของผู้ใช้ตามที่ฉันสงสัย?

php token csrf

— php_learner
แหล่งที่มา

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

— AbiusX

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

— mayankcpdixit

126

ใช่. โดยทั่วไปคุณต้องรักษาความปลอดภัยให้กับฟอร์มการลงชื่อเข้าใช้จากการโจมตี CSRF เช่นเดียวกับที่อื่น ๆ

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

ช่องโหว่มีลักษณะดังนี้:

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

เป็นตัวอย่างที่เกี่ยวข้องพิจารณาYouTube YouTube อนุญาตให้ผู้ใช้ดูบันทึกประวัติการดู "ของตนเอง" และแบบฟอร์มเข้าสู่ระบบของพวกเขามีความเสี่ยงต่อ CSRF! ดังนั้นผู้โจมตีสามารถตั้งค่าบัญชีด้วยรหัสผ่านที่พวกเขารู้เข้าสู่ระบบของเหยื่อใน YouTube โดยใช้บัญชีนั้น - สะกดรอยตามวิดีโอที่เหยื่อกำลังดู

มีการสนทนาบางอย่างในชุดความคิดเห็นนี้ที่บอกเป็นนัยว่าสามารถ "ใช้งานได้" สำหรับการละเมิดความเป็นส่วนตัวเช่นนั้น บางที แต่อ้างถึงหัวข้อในบทความ CSRF ของ Wikipedia :

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

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

— natevw
แหล่งที่มา

6

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

— A. Wilson

2

"มีอะไรที่ขัดขวางไม่ให้ผู้โจมตีร้องขอโทเค็น CSRF ของเขาและเพิ่งส่งสิ่งนั้น" - ใช่! นั่นคือสมมติฐานทั้งหมดที่อยู่เบื้องหลังตรรกะการป้องกัน CSRF เบราว์เซอร์ทำ / อนุญาตให้ส่งแบบฟอร์มเพื่อกำหนดเป้าหมายไปยังต้นทางอื่น แต่พวกเขาไม่เคย [จงใจ] อนุญาตให้ JS อ่านข้อมูลข้ามไซต์ยกเว้นตอนนี้ผ่านทาง opt-in CORS หากคุณตั้งค่า CORS ไม่ถูกต้องผู้โจมตีสามารถเปิดใช้งานการส่งแบบฟอร์ม (ซึ่งอาจรวมถึงโทเค็น CSRF ที่มีอยู่ในคุกกี้ ) แต่ไม่มีวิธีที่จะรู้โทเค็นเพื่อส่งสำเนาที่สองที่ต้องการ (เช่นในเนื้อหา / ส่วนหัว) ดังนั้นรหัส CSRF จะถูกปฏิเสธ

— natevw

7

ฉันคิดว่าความคิดเห็นสุดท้ายของคุณผิด (คุณเข้าใจผิดว่า A. Wilson กำลังพูดอะไร) เรากำลังจะบอกว่าผู้โจมตีสามารถโหลดhttp://good.com/login.htmlในลูกค้าคนหนึ่งแยกโทเค็น CSRF ซ้อนกันแล้วเผยแพร่http://bad.com/login.htmlที่มีรูปแบบการแก้ไขที่ส่งของเขาชื่อผู้ใช้รหัสผ่านและ token โดยไม่คำนึงถึงสิ่งที่ประเภทเหยื่อใน. ล ธ ใช้ไม่ได้เพราะคุณ' เราได้ลูกค้าสองราย: ผู้โจมตีและเหยื่อ ดังนั้นเพื่อย้ำคำถาม: การป้องกัน CSRF ใช้งานได้จริงสำหรับแบบฟอร์มการเข้าสู่ระบบหรือไม่

— Gili

8

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

— natevw

3

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

— you786

14

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

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

— จอน
แหล่งที่มา

2

ว้าวตอบกลับเร็วสุด! ขอบคุณมาก! ตอนนี้ฉันสามารถสร้างเว็บไซต์ของฉันได้อย่างมั่นใจ

— php_learner

21

ล็อกอิน CSRF ยังสามารถใช้สำหรับการโจมตีความเป็นส่วนตัวของผู้ใช้seclab.stanford.edu/websec/csrf/csrf.pdf

— squiddle

6

@squiddle: มันค่อนข้างเป็นกระดาษที่น่าสนใจขอบคุณสำหรับลิงค์ แต่มันขึ้นอยู่กับการเข้าสู่ระบบของผู้ใช้ด้วยบัญชีภายใต้การควบคุมของผู้โจมตีและสันนิษฐานว่าผู้ใช้จะไม่ตระหนักถึงบางสิ่งที่ไม่ถูกต้องและถือว่าผู้ใช้กำลังสร้างข้อมูลที่ละเอียดอ่อนซึ่งจะถูกเก็บไว้บนเซิร์ฟเวอร์ ดังนั้น IMHO จึงค่อนข้างจริงจังน้อยกว่า CSRF แบบ "คลาสสิค"

— จอน

6

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

— squiddle

1

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

— samthebest

0

ใช่เว็บไซต์อื่น ๆ ไม่สามารถเลียนแบบฟอร์มการเข้าสู่ระบบของคุณได้! ง่ายเหมือนที่

พวกเขาทำอะไรได้บ้างโดยทำ

ครั้งแรก: คุณไม่ต้องการที่จะอนุญาต
ประการที่สอง: แม้แต่กรณีความล้มเหลวที่เรียบง่ายเช่น:
- ปิดกั้นผู้ใช้เนื่องจากรหัสผ่านไม่ถูกต้องnไม่มี ครั้งสามารถหลีกเลี่ยงได้
- การแจ้งเตือนการแฮ็ก Flase สามารถป้องกันได้ ฯลฯ

— mayankcpdixit
แหล่งที่มา

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

— Snapey

@Snapey Browsers โดยทั่วไปไม่อนุญาตให้ JS อ่านข้อมูล CSRF การใช้ JS คุณไม่สามารถเลียนแบบคำขอส่งของแท้

— mayankcpdixit

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

— Snapey

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

— mayankcpdixit

-1

การตรวจสอบความถูกต้องของ CSRF การลงชื่อเข้าใช้ล่วงหน้าไม่ทำให้ IMHO มากเกินไป

ขอบคุณ @squiddle สำหรับลิงค์: seclab.stanford.edu/websec/csrf/csrf.pdfเราสามารถอ่านได้ในหน้าแรก:

The most popular CSRF defense is to include a secret
token with each request and to validate that the received
token is correctly bound to the user’s session,
preventing CSRF by forcing the attacker to guess the
session’s token.

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

บางทีผู้โจมตีสามารถลองเดาชื่อผู้ใช้ของไซต์ของคุณ สิ่งที่ฉันทำถ้าที่อยู่ IP พยายามเดาชื่อผู้ใช้ 10 ชื่อที่ไม่สำเร็จฉันก็แค่บัญชีดำ

— Patrice Gagnon
แหล่งที่มา