คำถามติดแท็ก owasp

ฉันกำลังทำการทดสอบการเจาะระบบบน localhost ของฉันด้วย OWASP ZAP และมันรายงานข้อความนี้ต่อไป ไม่ได้ตั้งค่าส่วนหัว Anti-MIME-Sniffing X-Content-Type-Options เป็น 'nosniff' การตรวจสอบนี้เป็นการเฉพาะสำหรับ Internet Explorer 8 และ Google Chrome ตรวจสอบให้แน่ใจว่าแต่ละหน้าตั้งค่าส่วนหัวของประเภทเนื้อหาและ X-CONTENT-TYPE-OPTIONS หากไม่ทราบส่วนหัวของประเภทเนื้อหา ฉันไม่รู้ว่าสิ่งนี้หมายถึงอะไรและฉันไม่พบสิ่งใดทางออนไลน์ ฉันได้ลองเพิ่ม: <meta content="text/html; charset=UTF-8; X-Content-Type-Options=nosniff" http-equiv="Content-Type" /> แต่ฉันยังคงได้รับการแจ้งเตือน วิธีการตั้งค่าพารามิเตอร์ที่ถูกต้องคืออะไร?

292 html  http-headers  meta  owasp  penetration-testing 

ฉันพยายามเข้าใจปัญหาทั้งหมดด้วย CSRF และวิธีที่เหมาะสมในการป้องกัน (ทรัพยากรที่ฉันได้อ่านทำความเข้าใจและเห็นด้วยกับ: OWASP CSRF ป้องกันแผ่นโกง , คำถามเกี่ยวกับ CSRF .) ตามที่ฉันเข้าใจแล้วช่องโหว่รอบ ๆ CSRF ถูกนำเสนอโดยการสันนิษฐานว่า (จากมุมมองของเว็บเซิร์ฟเวอร์) คุกกี้เซสชันที่ถูกต้องในคำขอ HTTP ขาเข้าที่สะท้อนถึงความต้องการของผู้ใช้ที่ผ่านการรับรองความถูกต้อง แต่คุกกี้ทั้งหมดสำหรับโดเมนต้นทางนั้นแนบมากับเบราว์เซอร์อย่างน่าอัศจรรย์ดังนั้นจริงๆแล้วเซิร์ฟเวอร์ทั้งหมดสามารถอนุมานจากการมีคุกกี้เซสชันที่ถูกต้องในคำขอคือคำขอนั้นมาจากเบราว์เซอร์ที่มีเซสชันที่มีการรับรองความถูกต้อง มันไม่สามารถคิดอะไรเกี่ยวกับรหัสได้อีกใช้งานในเบราว์เซอร์นั้นหรือไม่ว่ามันจะสะท้อนถึงความต้องการของผู้ใช้จริงหรือไม่ วิธีการป้องกันสิ่งนี้คือการรวมข้อมูลการรับรองความถูกต้องเพิ่มเติม ("โทเค็น CSRF") ในคำขอซึ่งดำเนินการด้วยวิธีการอื่นนอกเหนือจากการจัดการคุกกี้อัตโนมัติของเบราว์เซอร์ คุกกี้เซสชั่นรับรองความถูกต้องของผู้ใช้ / เบราว์เซอร์และโทเค็น CSRF รับรองความถูกต้องของรหัสที่ทำงานในเบราว์เซอร์ ดังนั้นหากคุณใช้คุกกี้เซสชันเพื่อตรวจสอบสิทธิ์ผู้ใช้แอปพลิเคชันเว็บของคุณคุณควรเพิ่มโทเค็น CSRF ในการตอบกลับแต่ละครั้งและต้องการโทเค็น CSRF ที่ตรงกันในแต่ละคำขอ (กลายพันธุ์) จากนั้นโทเค็น CSRF จะทำการส่งไปกลับจากเซิร์ฟเวอร์หนึ่งไปยังเบราว์เซอร์กลับไปที่เซิร์ฟเวอร์เพื่อพิสูจน์ว่าเซิร์ฟเวอร์ที่หน้านั้นร้องขอนั้นได้รับการอนุมัติจาก (สร้างโดย, แม้แต่) เซิร์ฟเวอร์นั้น ตามคำถามของฉันซึ่งเกี่ยวกับวิธีการขนส่งเฉพาะที่ใช้สำหรับโทเค็น CSRF นั้นในการไปกลับนั้น ดูเหมือนเป็นเรื่องธรรมดา (เช่นในAngularJS , Django , …

284 security  cookies  web  csrf  owasp 

ฉันค้นหามากและอ่านเอกสาร PHP $ _SERVERด้วย ฉันมีสิทธิ์ที่จะใช้สำหรับสคริปต์ PHP ของฉันสำหรับคำจำกัดความลิงก์แบบง่ายที่ใช้ทั่วทั้งไซต์ของฉันหรือไม่? $_SERVER['SERVER_NAME'] ขึ้นอยู่กับไฟล์ปรับแต่งของเว็บเซิร์ฟเวอร์ของคุณ (Apache2 ในกรณีของฉัน) และแตกต่างกันไปตามคำสั่งไม่กี่: (1) VirtualHost, (2) ServerName, (3) UseCanonicalName ฯลฯ $_SERVER['HTTP_HOST'] ขึ้นอยู่กับการร้องขอจากลูกค้า $_SERVER['HTTP_HOST']ดังนั้นก็จะดูเหมือนกับผมว่าคนที่เหมาะสมที่จะใช้ในการที่จะทำให้ฉันเป็นสคริปต์ที่เข้ากันได้เป็นไปได้ที่จะเป็น สมมติฐานนี้ถูกต้องหรือไม่ ความคิดเห็นติดตามผล: ฉันเดาว่าฉันได้รับความหวาดระแวงเล็กน้อยหลังจากอ่านบทความนี้และสังเกตว่าคนบางคนพูดว่า "พวกเขาจะไม่เชื่อถือ$_SERVERvars ใด ๆ": http://markjaquith.wordpress.com/2009/09/21/php-server-vars-not-safe-in-forms-or-links/ http://php.net/manual/en/reserved.variables.server.php#89567 (ความคิดเห็น: Vladimir Kornea 14-Mar-2009 01:06) เห็นได้ชัดว่าการอภิปรายส่วนใหญ่เกี่ยวกับ$_SERVER['PHP_SELF']และทำไมคุณไม่ควรใช้ในแอตทริบิวต์การกระทำแบบฟอร์มโดยไม่ต้องหลบหนีที่เหมาะสมเพื่อป้องกันการโจมตี XSS ข้อสรุปของฉันเกี่ยวกับคำถามเดิมของฉันคือการ "ปลอดภัย" เพื่อใช้$_SERVER['HTTP_HOST']สำหรับลิงก์ทั้งหมดในเว็บไซต์โดยไม่ต้องกังวลเกี่ยวกับการโจมตี XSS แม้เมื่อใช้ในรูปแบบ โปรดแก้ไขฉันหากฉันผิด

167 php  apache  security  owasp 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน2 ปีที่ผ่านมา ปรับปรุงคำถามนี้ ฉันต้องพัฒนาเว็บแอปพลิเคชันที่จะทำงานแบบออฟไลน์เป็นเวลานาน เพื่อให้สิ่งนี้เป็นไปได้ฉันไม่สามารถหลีกเลี่ยงการบันทึกข้อมูลที่ละเอียดอ่อน (ข้อมูลส่วนบุคคล แต่ไม่ใช่ชนิดข้อมูลที่คุณจะเก็บแฮชเท่านั้น) ในที่จัดเก็บในตัวเครื่อง ฉันยอมรับว่านี่ไม่ใช่วิธีปฏิบัติที่แนะนำ แต่มีตัวเลือกเล็กน้อยที่ฉันทำต่อไปนี้เพื่อรักษาความปลอดภัยข้อมูล: การเข้ารหัสทุกอย่างที่อยู่ในที่จัดเก็บในตัวเครื่องโดยใช้ไลบรารี stanford javascript crypto และ AES-256 รหัสผ่านผู้ใช้เป็นรหัสการเข้ารหัสและไม่ได้เก็บไว้ในอุปกรณ์ ให้บริการเนื้อหาทั้งหมด (เมื่อออนไลน์) จากเซิร์ฟเวอร์ที่เชื่อถือได้เดียวผ่าน ssl การตรวจสอบความถูกต้องของข้อมูลทั้งหมดที่ไปและกลับจากที่จัดเก็บในตัวเครื่องบนเซิร์ฟเวอร์โดยใช้โครงการ antaspam ของ owasp ในส่วนเครือข่ายของ appcache ไม่ใช่ใช้ * และแสดงรายการเฉพาะ URIs ที่จำเป็นสำหรับการเชื่อมต่อกับเซิร์ฟเวอร์ที่เชื่อถือได้แทน โดยทั่วไปแล้วพยายามใช้แนวทางที่แนะนำในแผ่นโกง OWASP XSS ฉันขอขอบคุณที่ปีศาจมักจะอยู่ในรายละเอียดและรู้ว่ามีจำนวนมากสงสัยเกี่ยวกับการจัดเก็บในท้องถิ่นและการรักษาความปลอดภัยตามจาวาสคริปต์โดยทั่วไป ทุกคนสามารถแสดงความคิดเห็นว่ามี: ข้อบกพร่องพื้นฐานในแนวทางข้างต้น? วิธีแก้ปัญหาที่เป็นไปได้สำหรับข้อบกพร่องดังกล่าว? มีวิธีใดที่ดีกว่าในการรักษาความปลอดภัยที่จัดเก็บในตัวเครื่องเมื่อแอปพลิเคชัน html 5 ต้องทำงานแบบออฟไลน์เป็นเวลานาน ขอบคุณสำหรับความช่วยเหลือใด ๆ

161 html  security  local-storage  html5-appcache  owasp