การเข้ารหัสฝั่งไคลเอ็นต์: จะป้องกันการใช้งานที่ประสงค์ร้ายได้อย่างไร?

60

ในช่วงไม่กี่ปีที่ผ่านมาแนวโน้มของแอปพลิเคชันฝั่งไคลเอ็นต์ (เบราว์เซอร์) ได้ถูกถอดออกจริงๆ

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

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

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

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

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

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

ฉันเดาคำถามทั่วไปของฉันคือ - เราจะป้องกันแอปพลิเคชันฝั่งไคลเอ็นต์ได้อย่างไร

javascript  web-applications  browser  client-side 
— Gaz_Edge
แหล่งที่มา
24
ด้วยเหตุผลใดก็ตามที่คุณไม่มีแอพนี้สื่อสารกับเซิร์ฟเวอร์ของคุณเองจากนั้นเซิร์ฟเวอร์ของคุณจะส่งต่อคำร้องขอเหล่านั้นไปยังบริการภายนอกที่คุณต้องการใช้ (บริการดังกล่าวจำนวนมากจะห้ามมิให้ใช้บริการด้วยวิธีนี้ต่อไป)
— thorsten müller
11
นี่คือเหตุผลที่คีย์ API ไม่มีจุดหมาย เซิร์ฟเวอร์ไม่ควรเชื่อถือแอปที่ส่งคำสั่ง ควรเชื่อถือผู้ใช้เท่านั้น
— Kevin Panko
42
ฉันไม่เคยเห็นบุคคลที่มีสติใด ๆ เคยนิยามว่า "แอปพลิเคชันฝั่งไคลเอ็นต์" เป็น "ไม่ว่าในกรณีใดก็ตามที่ไม่เคยสื่อสารกับเซิร์ฟเวอร์" - ซึ่งดูเหมือนว่าเป็นชาวฟางมากกว่าอาร์กิวเมนต์ที่สมเหตุสมผล เห็นได้ชัดว่ามีบางสิ่งที่คุณต้องจัดการในฝั่งเซิร์ฟเวอร์ แต่ส่วนใหญ่ของการกระทำที่สามารถทำได้ในประเทศได้โดยไม่มีปัญหาซึ่งจะเปิดอย่างมากมายปรับปรุงการตอบสนองและความยืดหยุ่น ..
— Voo
4
คุณเห็นการผลักดันไปยัง "แอปเบราว์เซอร์เท่านั้น" ที่ใด ฉันไม่เคยเห็นอะไรที่เหมือนกับสิ่งที่คุณกำลังอธิบายการเก็บความลับในรหัสลูกค้าในความคิดที่ไม่ดีอย่างบ้าคลั่งแม้แต่คนที่อยู่ข้างหน้าสุด ๆ ที่ฉันรู้ว่าจะไม่ทำอย่างนั้น
— Wheeyls
2
ความพยายามใด ๆ ในการปกป้องทรัพยากรที่ปลอดภัยด้านไคลเอ็นต์นั้นถึงวาระอีกต่อไปเพราะละเมิดกฎหมายความปลอดภัยที่ไม่เปลี่ยนรูปแบบหลายข้อ # 2/3 - หากซอฟต์แวร์ของคุณทำงานบนคอมพิวเตอร์ฝ่ายตรงข้ามไม่ใช่คอมพิวเตอร์ของคุณตามคำจำกัดความและคุณได้สูญเสียไปแล้ว # 7 ความพยายามในการปกป้องทรัพยากรด้วยการเข้ารหัสจะถึงวาระเนื่องจากคุณต้องให้คีย์ถอดรหัสแก่ลูกค้าด้วย # 10 ไม่มีเทคโนโลยีใดสามารถแก้ไขปัญหาข้างต้นได้ blogs.technet.com/b/rhalbheer/archive/2011/06/16/…
— Dan Neely

คำตอบ:

200

คุณทำไม่ได้และยิ่งมีคนเข้าใจสิ่งนี้มากขึ้นเท่าไหร่พวกเขาก็ยิ่งเข้าใจมากขึ้นเท่านั้น

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

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

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

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

— Kilian Foth
แหล่งที่มา
6
แต่จะนำสิ่งนี้ไปใช้ในมุมมอง: สิ่งนี้เป็นจริงสำหรับทุก ๆ ซอฟต์แวร์ไม่ว่าจะเป็นระบบปฏิบัติการหรือชุดธุรกรรม ในที่สุดก็มีผู้ทำรหัสที่ดีมากออกไปและคุณสามารถเพิ่มบาร์ที่มีโอกาสสูงมากพอถ้าไม่มีแรงจูงใจทางการเงินในทันทีเพื่อแฮ็คซอฟต์แวร์ของคุณ!
— Falco
5
ทุกวันนี้ บริษัท ต่างๆได้ทำการข่มขู่การดำเนินการทางกฎหมายกับผู้ที่แฮ็คเนื้อหาที่ได้รับจากพวกเขาก่อนทำการประมวลผล (เช่นผ่านตัวบล็อคโฆษณา) นั่นแสดงให้เห็นว่าการกระทำทางเทคนิคเป็นไปไม่ได้เท่านั้น
— Kilian Foth
62
หากฉันอาจอธิบายรายละเอียดในสองประโยคแรกคนที่ละเอียดอ่อนมักพลาดคือจุดที่แอพเบราว์เซอร์ฝั่งไคลเอ็นต์ใช้เพื่อยกภาระหนัก เซิร์ฟเวอร์ของคุณยังคงรับผิดชอบการดำเนินการที่เชื่อถือได้เช่นการส่งอีเมลหรือการเข้าถึงข้อมูล การให้ไคลเอ็นต์แสดงกราฟจากข้อมูลนั้นจะช่วยคุณประหยัดเวลา CPU (และเงิน) โดยไม่ต้องเปลี่ยนรูปแบบการรักษาความปลอดภัย
— ssube
11
@Gaz_Edge สิ่งสำคัญคือต้องทราบว่าปัญหาที่นี่ไม่ใช่ว่าแอปฝั่งไคลเอ็นต์นั้นไม่ปลอดภัยโดยเนื้อแท้ ปัญหาคือการเขียนแอปฝั่งไคลเอ็นต์เหล่านี้ในลักษณะที่ต้องเชื่อถือลูกค้าด้วยข้อมูลที่คุณไม่ต้องการให้เป็นสาธารณะ เป็นไปได้ทั้งหมดที่จะเขียนแอปพลิเคชันที่มีลูกค้ามากซึ่งปลอดภัยพอ ๆ กับแอปพลิเคชันที่การประมวลผลส่วนใหญ่เกิดขึ้นบนเซิร์ฟเวอร์ (สำหรับข้อมูลเพิ่มเติมโปรดดูคำตอบของ jhocking )
— Ajedi32
7
@ Ajedi32 ปพลิเคชันฝั่งไคลเอ็นต์มีความไม่ปลอดภัย มันเป็นไปไม่ได้ที่จะออกแบบแอพที่ปลอดภัยถ้าลอจิกใด ๆ ที่ทำกับฝั่งไคลเอ็นต์ไม่ได้ตรวจสอบฝั่งเซิร์ฟเวอร์ ณ จุดนั้นตรรกะฝั่งไคลเอ็นต์จะกลายเป็นความดีของ UI หรือวิธีในการลดการตรวจสอบขั้นพื้นฐาน แต่ทุกอย่างจะต้องถูกตรวจสอบบนเซิร์ฟเวอร์เสมอ !! .
69

กฎที่นี่คือ:

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

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

— jhocking
แหล่งที่มา
28

นี่เป็นกรณีที่ทำให้แอปพลิเคชันฝั่งไคลเอ็นต์สมบูรณ์ไม่เหมาะสม

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

— Jan Hudec
แหล่งที่มา
11
หมายเหตุ: แม้ว่าจะเป็นการดีในการตรวจสอบแบบฟอร์มฝั่งไคลเอ็นต์ แต่ก็ไม่ลืมที่จะตรวจสอบฝั่งเซิร์ฟเวอร์ด้วย! เมื่อคุณส่งรหัสลูกค้าไปยังเบราว์เซอร์มันจะหยุดเป็นรหัสของคุณ! คุณต้องตรวจสอบทุกบิตที่ส่งอีกครั้ง!
— Josef
17

ย่อหน้ากลางของคุณคือหัวใจของปัญหา:

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

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

สำหรับ.jsไฟล์ที่คุณได้รับคุณแน่ใจหรือว่ามันมีความหมายสำหรับเบราว์เซอร์? อาจเป็นไลบรารี node.js หรือไม่

— แบรนดอน
แหล่งที่มา
4
+1 สำหรับข้อเสนอแนะที่ดีจริงๆที่ไฟล์ JS มีไว้สำหรับเซิร์ฟเวอร์ NodeJS
— Machinarius
11

ลองย้อนกลับไปจากนี้และมองในระดับที่สูงขึ้น .. เราจะต้อง .. Eudora หรือ outlook (แอปด้านลูกค้าไม่จำเป็นต้องใช้เบราว์เซอร์) เคยทำให้เกิดการสูญเสียทางการเงินสำหรับ บริษัท ใด ๆ หรือไม่? ไม่ทุกคนสามารถเขียนถึง POP / SMTP API และเป็นลูกค้าได้ แต่ไม่เสียกับเซิร์ฟเวอร์ เซิร์ฟเวอร์ไม่ได้ จำกัด การกระทำของลูกค้า, การคำนวณ, การจัดเก็บ, อุณหภูมิ, ขนาดของดิสก์, ขนาด RAM, มอนิเตอร์ DPI, GPU, FPU yada yada ของลูกค้า แต่ระบุสิ่งที่จะตอบได้อย่างแน่นอน คุณเคยได้ยินว่าเร่งหรือใช้ MS-Money เพื่อเจาะเข้าธนาคารหรือไม่?

แอปเบราว์เซอร์ของคุณ (เช่นฝั่งไคลเอ็นต์) สามารถใช้สถาปัตยกรรมเดียวกันได้

  1. คุณสร้างเซิร์ฟเวอร์ของคุณด้วย API (ซึ่ง BTW ซึ่งมักจะลงไปที่อนุพันธ์ของ GET POST HEAD เป็นต้น)
  2. บนเซิร์ฟเวอร์ตรวจสอบให้แน่ใจว่า API พูดคุยกับไคลเอนต์ที่ผ่านการตรวจสอบความถูกต้องและมีการระบุตัวตนสำหรับการโทรทุกครั้ง
  3. จากนั้นคุณไม่สนใจว่าใครเป็นลูกค้า
  4. แล้วคุณไม่สนหรอกว่าจะเป็นเบราว์เซอร์อุปกรณ์คุกแก้ว Google แก้วดอส 3.1 หรือ Nexus ใหม่เอี่ยมอยู่ในมือของเทคโนโลเบะผู้ยิ่งใหญ่ผู้ยิ่งใหญ่ผู้ยิ่งใหญ่ซึ่งเดินทางข้ามเวลาไปยังปี 2014 และคิดถึงทุกคน เทคโนโลยีที่ท่วมท้นในช่วง 15 ปีที่ผ่านมา
  5. ตอนนี้คุณสามารถเริ่มการโหลดทุกอย่างไปยังฝั่งไคลเอ็นต์

SoapBoxBegin

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

SoapBoxEnd

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

— LMSingh
แหล่งที่มา
6

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

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

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

— Matt Klinker
แหล่งที่มา
4

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

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

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

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

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

— gnasher729
แหล่งที่มา
0

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

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

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

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

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

— Depado
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.