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

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

หากเป็นลูกค้าของคุณ (JavaScript ของคุณ) ดังนั้นโดยทั้งหมดแล้วสลับ คุณกำลังสูญเสียแบนด์วิดท์โดยการส่งข้อมูลทั้งหมดในแต่ละส่วนหัว HTTP

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

คุณจะต้องออกจากคุกกี้เซสชันของคุณเป็นคุกกี้อย่างใดอย่างหนึ่ง

ตามความแตกต่างทางเทคนิคและความเข้าใจของฉัน:

1. นอกเหนือจากการบันทึกข้อมูลแบบเก่าคุ้กกี้ยังให้ข้อ จำกัด4096ไบต์ (4095 อันที่จริง) - ต่อคุกกี้ ที่จัดเก็บในตัวเครื่องมีขนาดใหญ่ถึง5 เมกะไบต์ต่อโดเมน - ดังนั้นคำถามจะกล่าวถึงด้วย

2. localStorageเป็นการใช้งานส่วนStorageต่อประสาน มันเก็บข้อมูลที่มีไม่มีวันหมดอายุและได้รับการล้างเพียงผ่าน JavaScript หรือเบราว์เซอร์ล้างแคช / ข้อมูลที่เก็บไว้ - แตกต่างคุกกี้หมดอายุ

ในบริบทของ JWTs Stormpath ได้เขียนบทความที่เป็นประโยชน์อย่างเป็นธรรมโดยสรุปวิธีที่เป็นไปได้ในการจัดเก็บและข้อดี (dis-) ที่เกี่ยวข้องกับแต่ละวิธี

นอกจากนี้ยังมีภาพรวมสั้น ๆ ของการโจมตี XSS และ CSRF และวิธีที่คุณสามารถต่อสู้กับพวกเขา

ฉันได้แนบตัวอย่างสั้น ๆ ของบทความด้านล่างในกรณีที่บทความของพวกเขาออฟไลน์ / เว็บไซต์ของพวกเขาล้มเหลว

การจัดเก็บในท้องถิ่น

ปัญหา:

Web Storage (localStorage / sessionStorage) สามารถเข้าถึงได้ผ่าน JavaScript ในโดเมนเดียวกัน ซึ่งหมายความว่า JavaScript ใด ๆ ที่ทำงานบนไซต์ของคุณจะสามารถเข้าถึงที่เก็บข้อมูลบนเว็บได้และด้วยเหตุนี้จึงมีความเสี่ยงที่จะถูกโจมตีจากสคริปต์ข้ามไซต์ (XSS) XSS สั้นเป็นประเภทของช่องโหว่ที่ผู้โจมตีสามารถฉีด JavaScript ที่จะทำงานบนหน้าของคุณ การโจมตี XSS พื้นฐานพยายามฉีด JavaScript ผ่านอินพุตแบบฟอร์มโดยที่ผู้โจมตีแจ้งเตือน ('คุณถูกแฮ็ก'); ลงในแบบฟอร์มเพื่อดูว่าเบราว์เซอร์นั้นทำงานหรือไม่และผู้ใช้รายอื่นสามารถดูได้

การป้องกัน:

เพื่อป้องกัน XSS การตอบสนองทั่วไปคือการหลบหนีและเข้ารหัสข้อมูลที่ไม่น่าเชื่อถือทั้งหมด แต่มันก็ยังห่างไกลจากเรื่องราวทั้งหมด ในปี 2015 เว็บแอพทันสมัยใช้ JavaScript ที่โฮสต์บน CDNs หรือโครงสร้างพื้นฐานภายนอก เว็บแอพที่ทันสมัยประกอบด้วยห้องสมุด JavaScript ของบุคคลที่สามสำหรับการทดสอบ A / B การวิเคราะห์ช่องทาง / การตลาดและโฆษณา เราใช้ตัวจัดการแพคเกจเช่น Bower เพื่อนำเข้ารหัสของผู้อื่นในแอพของเรา

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

ในฐานะกลไกการจัดเก็บข้อมูล Web Storage ไม่บังคับใช้มาตรฐานความปลอดภัยใด ๆ ในระหว่างการถ่ายโอน ใครก็ตามที่อ่านที่เก็บข้อมูลบนเว็บและใช้งานนั้นจะต้องดำเนินการตรวจสอบสถานะของตนเพื่อให้แน่ใจว่าพวกเขาส่ง JWT ผ่าน HTTPS และไม่ใช้ HTTP

คุ้กกี้

ปัญหา:

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

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

การป้องกัน:

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

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

ตัวอย่างเช่น AngularJS มีวิธีการตรวจสอบว่าคุกกี้สามารถเข้าถึงได้โดยโดเมนของคุณเท่านั้น ส่งตรงจาก AngularJS docs:

เมื่อทำการร้องขอ XHR บริการ $ http จะอ่านโทเค็นจากคุกกี้ (ตามค่าเริ่มต้น XSRF-TOKEN) และตั้งเป็นส่วนหัว HTTP (X-XSRF-TOKEN) เนื่องจาก JavaScript ที่ทำงานบนโดเมนของคุณเท่านั้นที่สามารถอ่านคุกกี้เซิร์ฟเวอร์ของคุณจึงมั่นใจได้ว่า XHR นั้นมาจาก JavaScript ที่ทำงานบนโดเมนของคุณ คุณสามารถทำให้การปกป้อง CSRF ไร้สัญชาติได้โดยการรวมการxsrfTokenอ้างสิทธิ์ JWT:

{
  "iss": "http://galaxies.com",
  "exp": 1300819380,
  "scopes": ["explorer", "solar-harvester", "seller"],
  "sub": "tom@andromeda.com",
  "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
}

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

บทความเต็มสามารถพบได้ที่นี่: https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

พวกเขายังมีบทความที่มีประโยชน์เกี่ยวกับวิธีการออกแบบและใช้ JWT ที่ดีที่สุดโดยคำนึงถึงโครงสร้างของโทเค็นเอง: https://stormpath.com/blog/jwt-the-right-way/

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

คุ้กกี้

ข้อดี

• การสนับสนุนแบบดั้งเดิม (มีมานานแล้ว)
• ข้อมูลถาวร
• วันหมดอายุ

จุดด้อย

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

ที่จัดเก็บในตัวเครื่อง

ข้อดี

• สนับสนุนโดยเบราว์เซอร์ที่ทันสมัยที่สุด
• ข้อมูลถาวรที่จัดเก็บโดยตรงในเบราว์เซอร์
• กฎแหล่งกำเนิดเดียวกันนำไปใช้กับข้อมูลหน่วยเก็บภายใน
• ไม่ได้ถูกส่งไปพร้อมกับทุกคำขอ HTTP
• ~ 5MB พื้นที่เก็บข้อมูลต่อโดเมน (นั่นคือ 5120KB)

จุดด้อย

• ไม่รองรับอะไรมาก่อน: IE 8, Firefox 3.5, Safari 4, Chrome 4, Opera 10.5, iOS 2.0, Android 2.0
• หากเซิร์ฟเวอร์ต้องการข้อมูลลูกค้าที่เก็บไว้คุณต้องส่งมัน

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

/* 
* function body that test if storage is available
* returns true if localStorage is available and false if it's not
*/
function lsTest(){
    var test = 'test';
    try {
        localStorage.setItem(test, test);
        localStorage.removeItem(test);
        return true;
    } catch(e) {
        return false;
    }
}

/* 
* execute Test and run our custom script 
*/
if(lsTest()) {
    // window.sessionStorage.setItem(name, 1); // session and storage methods are very similar
    window.localStorage.setItem(name, 1);
    console.log('localStorage where used'); // log
} else {
    document.cookie="name=1; expires=Mon, 28 Mar 2016 12:00:00 UTC";
    console.log('Cookie where used'); // log
}

"ค่า localStorage บนหน้า Secure (SSL) ถูกแยกออก" เนื่องจากมีคนสังเกตเห็นว่า localStorage จะไม่สามารถใช้ได้หากคุณเปลี่ยนจากโปรโตคอลที่ปลอดภัย 'http' เป็น 'https' ซึ่งคุกกี้จะยังคงเข้าถึงได้ นี่เป็นสิ่งสำคัญที่ควรระวังหากคุณทำงานกับโปรโตคอลที่ปลอดภัย

ความเร็วในการเก็บข้อมูลในเครื่องนั้นขึ้นอยู่กับเบราว์เซอร์ที่ไคลเอ็นต์ใช้งานรวมถึงระบบปฏิบัติการ Chrome หรือ Safari บน Mac อาจเร็วกว่า Firefox บนพีซีโดยเฉพาะกับ API ที่ใหม่กว่า เช่นเคยการทดสอบคือเพื่อนของคุณ (ฉันไม่สามารถหามาตรฐานได้)

ฉันไม่เห็นความแตกต่างอย่างมากในคุกกี้กับที่เก็บข้อมูลในตัวเครื่อง นอกจากนี้คุณควรกังวลเกี่ยวกับปัญหาความเข้ากันได้: เบราว์เซอร์บางตัวไม่ได้เริ่มสนับสนุน HTML5 API ใหม่ดังนั้นคุกกี้จะเป็นทางออกที่ดีที่สุดสำหรับความเร็วและความเข้ากันได้ของคุณ

นอกจากนี้ยังเป็นมูลค่าการกล่าวขวัญว่า localStorageไม่สามารถใช้เมื่อผู้ใช้เรียกดูในโหมด "ส่วนตัว" ในมือถือบางรุ่นของ Safari

อ้างถึงจาก MDN ( https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage ):

หมายเหตุ: เริ่มต้นด้วย iOS 5.1, Safari Mobile เก็บข้อมูล localStorage ในโฟลเดอร์แคชซึ่งอาจมีการล้างข้อมูลเป็นครั้งคราวตามคำสั่งของระบบปฏิบัติการโดยทั่วไปหากพื้นที่ว่าง โหมดการดูเว็บส่วนตัวของ Safari Mobile ยังป้องกันการเขียนลงใน localStorage ทั้งหมด

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

LOCAl และ Session data data ในรูปแบบ JSON จึงง่ายต่อการแยกวิเคราะห์ แต่ข้อมูลคุกกี้อยู่ในรูปแบบสตริง

คุกกี้ :

1. แนะนำก่อน HTML5
2. มีวันหมดอายุ
3. ลบโดย JS หรือลบข้อมูลการท่องเว็บของเบราว์เซอร์หรือหลังจากวันที่หมดอายุ
4. จะส่งไปยังเซิร์ฟเวอร์ต่อคำขอแต่ละครั้ง
5. ความจุคือ 4KB
6. สตริงเท่านั้นที่สามารถเก็บในคุกกี้
7. คุกกี้มีสองประเภทคือแบบถาวรและแบบเซสชัน

การจัดเก็บในท้องถิ่น:

1. แนะนำด้วย HTML5
2. ไม่มีวันที่หมดอายุ
3. ลบโดย JS หรือลบข้อมูลการท่องเว็บของเบราว์เซอร์
4. คุณสามารถเลือกได้ว่าจะส่งข้อมูลเมื่อใดไปยังเซิร์ฟเวอร์
5. ความจุ 5MB
6. ข้อมูลถูกเก็บไว้อย่างไม่มีกำหนดและจะต้องเป็นสตริง
7. มีเพียงประเภทเดียวเท่านั้น