স্টেটলেস (= সেশনলেস) প্রমাণীকরণ ব্যবহার করার সময় সিএসআরএফ টোকেন প্রয়োজনীয়?

Question

অ্যাপ্লিকেশনটি রাষ্ট্রবিহীন প্রমাণীকরণের উপর নির্ভর করে (এইচএমএসি জাতীয় কিছু ব্যবহার করে) তখন কি সিএসআরএফ সুরক্ষা ব্যবহার করা দরকার?

উদাহরণ:

• আমরা একটি একক পৃষ্ঠার অ্যাপ্লিকেশান পেয়ে গেলে (অন্যথায় আমরা একে লিঙ্কে টোকেন যোগ করতে হবে: <a href="...?token=xyz">...</a>।

• ব্যবহারকারী নিজেকে ব্যবহার করে প্রমাণীকরণ করে POST /auth। সফল প্রমাণীকরণে সার্ভারটি কিছু টোকেন ফিরিয়ে দেবে।

• টোকনটি জাভাস্ক্রিপ্টের মাধ্যমে একক পৃষ্ঠার অ্যাপের অভ্যন্তরে কিছু পরিবর্তনশীলতে সংরক্ষণ করা হবে in

• এই টোকেনটি যেমন নিষিদ্ধ ইউআরএলগুলিতে অ্যাক্সেস করতে ব্যবহৃত হবে /admin।

• টোকেনটি সর্বদা এইচটিটিপি শিরোনামের অভ্যন্তরে প্রেরণ করা হবে।

• এখানে কোনও এইচটিপি অধিবেশন এবং কোনও কুকিজ নেই।

আমি যতদূর বুঝতে পারি, (?!) ক্রস সাইট আক্রমণ ব্যবহার করার কোনও সম্ভাবনা থাকা উচিত নয়, কারণ ব্রাউজারটি টোকেন সংরক্ষণ করবে না, এবং তাই এটি স্বয়ংক্রিয়ভাবে এটি সার্ভারে প্রেরণ করতে পারে না (কুকিজ / সেশন).

আমি কিছু অনুপস্থিত করছি?

Comments

বেসিক আথ সম্পর্কে সাবধানতা অবলম্বন করুন। অনেক ব্রাউজার স্বয়ংক্রিয়ভাবে বাকী অধিবেশনটির জন্য প্রাথমিক লেখক শিরোনাম প্রেরণ করবে। এটি কুকি লেখকের মতো সিএসআরএফের পক্ষে দুর্বল হিসাবে বুনিয়াদি লেখক তৈরি করতে পারে।

— phylae

Answer 1

প্রমাণীকরণের জন্য কোনও কুকি ব্যবহার করে আমি সিএসআরএফ + সম্পর্কে কিছু তথ্য পেয়েছি :

1. https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
   "যেহেতু আপনি কুকিজের উপর নির্ভর করছেন না, তাই আপনাকে ক্রস সাইটের অনুরোধগুলির বিরুদ্ধে রক্ষা করার দরকার নেই"

2. http://angular-tips.com/blog/2014/05/json-web-tokens-intr پيداوار/
   "আমরা যদি কুকিজের পথে নামি তবে ক্রস সাইটের অনুরোধগুলি এড়াতে আপনার সত্যই সিএসআরএফ করা দরকার That এটি আমরা যা করতে পারি জেডাব্লুটিটি ব্যবহার করার সময় ভুলে যাবেন যেমনটি আপনি দেখতে পাবেন "
   (জেডব্লিউটি = জসন ওয়েব টোকন, স্টেটলেস অ্যাপ্লিকেশনের জন্য টোকন ভিত্তিক প্রমাণীকরণ)

3. http://www.jamesward.com/2013/05/13/securing-single-page-apps-and-rest-services
   "সিএসআরএফ দুর্বলতার ঝুঁকি না নিয়ে প্রমাণীকরণের সবচেয়ে সহজ উপায় হ'ল ব্যবহারকারীকে সনাক্তকরণের জন্য কুকি ব্যবহার করা এড়ানো to "

4. http://sitr.us/2011/08/26/cookies-are-bad-for-you.html
   "সিএসআরএফের সাথে সবচেয়ে বড় সমস্যা হ'ল কুকিজ এই ধরণের আক্রমণ থেকে একেবারে কোনও প্রতিরক্ষা দেয় না If আপনি যদি কুকি প্রমাণীকরণ ব্যবহার করছেন আপনার অবশ্যই সিএসআরএফের বিরুদ্ধে সুরক্ষার জন্য অতিরিক্ত ব্যবস্থা গ্রহণ করতে হবে you আপনি নিতে পারেন এমন সর্বাধিক প্রাথমিক সতর্কতা হ'ল জিইটি অনুরোধের প্রতিক্রিয়াতে আপনার অ্যাপ্লিকেশন কখনই কোনও পার্শ্ব প্রতিক্রিয়া না ঘটায় তা নিশ্চিত করে তোলা। "

প্রচুর পরিমাণে আরও পৃষ্ঠা রয়েছে, যা উল্লেখ করে যে আপনার যদি কোনও প্রমাণীকরণের জন্য কুকি ব্যবহার না করেন তবে আপনার কোনও সিএসআরএফ সুরক্ষা প্রয়োজন নেই। অবশ্যই আপনি অন্য যে কোনও কিছুর জন্য কুকি ব্যবহার করতে পারেন তবে এর session_idঅভ্যন্তরের মতো কিছু সংরক্ষণ করা এড়াতে পারেন।

---

আপনার যদি ব্যবহারকারীটির কথা মনে রাখতে হয় তবে দুটি বিকল্প রয়েছে:

1. localStorage: একটি ব্রাউজার কী-মান স্টোর। ব্যবহারকারী ব্রাউজার উইন্ডোটি বন্ধ করার পরেও সঞ্চিত ডেটা উপলব্ধ থাকবে। অন্যান্য ওয়েবসাইটের দ্বারা ডেটা অ্যাক্সেসযোগ্য নয়, কারণ প্রতিটি সাইট নিজস্ব স্টোরেজ পায়।

2. sessionStorage: এছাড়াও ব্রাউজার ডেটা স্টোর ইন। পার্থক্যটি হ'ল: ব্যবহারকারী ব্রাউজার উইন্ডোটি বন্ধ করলে ডেটা মুছে যায়। তবে এটি এখনও কার্যকর, যদি আপনার ওয়েব অ্যাপে একাধিক পৃষ্ঠা থাকে। সুতরাং আপনি নিম্নলিখিতটি করতে পারেন:

   • ব্যবহারকারী লগ ইন করে, তারপরে আপনি টোক ইনটি সঞ্চয় করুন sessionStorage
   • ব্যবহারকারী একটি লিঙ্ক ক্লিক করে, যা একটি নতুন পৃষ্ঠা লোড করে (= একটি আসল) লিঙ্ক, এবং কোনও জাভাস্ক্রিপ্ট সামগ্রী-প্রতিস্থাপন নয়)
   • আপনি এখনও থেকে টোকেন অ্যাক্সেস করতে পারেন sessionStorage
   • লগআউট করতে, আপনি হয় নিজেই থেকে টোকনটি মুছে ফেলতে পারেন sessionStorageবা ব্রাউজার উইন্ডোটি বন্ধ করার জন্য ব্যবহারকারী অপেক্ষা করতে পারেন, যা সমস্ত সঞ্চিত ডেটা সাফ করবে।

(উভয়ের জন্য এখানে দেখুন: http://www.w3schools.com/html/html5_webstorage.asp )

---

টোকেন লেখকের জন্য কোনও অফিসিয়াল স্ট্যান্ডার্ড আছে?

জেডব্লিউটি (জসন ওয়েব টোকন): আমি মনে করি এটি এখনও একটি খসড়া, তবে এটি ইতিমধ্যে অনেক লোক ব্যবহার করেছে এবং ধারণাটি সহজ এবং সুরক্ষিত বলে মনে হচ্ছে। (আইইটিএফ: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25 )
এছাড়াও অনেকগুলি ফ্রেমওয়ার্কের জন্য গ্রন্থাগার রয়েছে। এটির জন্য গুগল!

Comments

সিএসআরএফ-তে দুর্দান্ত সংক্ষিপ্তসার! আমি নোট করব যে লোকালস্টোরেজ বা সেশনসস্টারেজে আপনার টোকেনগুলি সংরক্ষণ করা এক্সএসএস আক্রমণগুলির পক্ষে ঝুঁকিপূর্ণ এবং সেই পৃষ্ঠায় স্ক্রিপ্টগুলি দিয়ে ডেটাটি দেখা যেতে পারে - সুতরাং যদি আপনার কোনও সিডিএন থেকে আপোস করা স্ক্রিপ্ট থাকে বা যদি আপনার কোনওটিতে দূষিত কোড থাকে জেএস লাইব্রেরি, তারা সেই সঞ্চয় স্থানগুলি থেকে টোকেন চুরি করতে পারে। দেখুন: stormpath.com/blog/… আমি মনে করি যে সবচেয়ে সুরক্ষিত পন্থা হ'ল কুকিতে একটি JWT + সিএসআরএফ টোকেন সংরক্ষণ করা এবং তারপরে অনুরোধ শিরোনামে এটির ভিতরে আপনার গণিত জেডাব্লুটি সিএসআরএফ টোকেন রাখুন।

— অ্যারন গ্রে

সম্পর্কিত: "আপনি নিতে পারেন যে সবচেয়ে মৌলিক সতর্কতা হ'ল এটি নিশ্চিত করা যে আপনার অ্যাপ্লিকেশন কখনই জিইটি অনুরোধের প্রতিক্রিয়াতে কোনও পার্শ্ব প্রতিক্রিয়া না করে।" কোনও সিএসআরএফ আক্রমণটির জন্য কোনও পোস্টের অনুরোধ নকল করা সম্ভব?

— কোস্টা

সার্ভার সাইড অ্যাপ্লিকেশন উপর নির্ভর করে, এটি সম্ভব হতে পারে। ওয়েব ফ্রেমওয়ার্ক রয়েছে, যা এমন কিছু ব্যবহার করে http://.../someRestResource?method=POST। সুতরাং এটি মূলত একটি GETঅনুরোধ, তবে সার্ভার অ্যাপ্লিকেশন এটি একটি POSTঅনুরোধ হিসাবে ব্যাখ্যা করে , কারণ এটি methodHTTP শিরোনামের পরিবর্তে প্যারামিটারটি ব্যবহার করার জন্য কনফিগার করা হয়েছিল । ...সাধারণ ওয়েব ব্রাউজারগুলির বিষয়ে, তারা একই-উত্স-নীতি প্রয়োগ করে এবং কেবল GETবিদেশী সার্ভারগুলিতে অনুরোধ সম্পাদন করবে । যদিও এটা পারে চালানো সম্ভব হবে POSTঅনুরোধ যদি ওয়েব ব্রাউজার ঐ ওয়েব মান (বাগ, ম্যালওয়্যার) প্রযোজ্য নয়।

— বেনিয়ামিন এম

এতে যোগ করুন Server Side App: একটি অনুরোধ সংস্থা পাঠানো এখনও সম্ভব নয়, কারণ সাধারণ ব্রাউজারগুলি এটি অনুমতি দেয় না। তবে, সার্ভার অ্যাপ্লিকেশন যদি method=POSTঅনুমতি দেয় তবে body={someJson}এটি ডিফল্ট অনুরোধের বডিটিকে ওভাররাইড করার অনুমতিও দিতে পারে। এটি সত্যই খারাপ এপিআই নকশা এবং অত্যন্ত ঝুঁকিপূর্ণ। যদিও যদি আপনার সার্ভার অ্যাপ্লিকেশনটিকে অনুমতি দেয় তবে http://...?method=POST&body={someJson}আপনি সেখানে কী করেছেন এবং কেন এবং কেন এটি প্রয়োজনীয় তা যদি আপনার সত্যই overthink করা উচিত। (আমি 99,9999% ক্ষেত্রে বলব এটি প্রয়োজনীয় নয় ) অতিরিক্তভাবে ব্রাউজারগুলি কেবল কয়েক কিলোবাইট এভাবে পাঠাতে পারে।

— বেনজামিন এম

@ বেঞ্জামিন এম লক্ষ্য করেছেন যে একই অরিজিন নীতি কেবল জাভা স্ক্রিপ্ট কোডটিকে ফলাফল অ্যাক্সেস করা থেকে বিরত রাখে যাতে অনুরোধটি "অবরুদ্ধ" করা হয় এটি আসলে সার্ভারে পৌঁছে যায় - jsbin.com/mewaxikuqo/edit?html,js, আউটপুট আমি কেবল এটি ফায়ার ফক্সে পরীক্ষা করেছি, তবে আপনি ডেভ সরঞ্জামগুলি খুলতে এবং দেখতে পাচ্ছেন যে এমনকি আপনি "ক্রস-অরিজিন অনুরোধ অবরুদ্ধ" পেয়েছেন রিমোট সার্ভারটি আসলে পুরো অনুরোধটি দেখতে পাবে। এজন্য আপনার সমস্ত পোস্ট অনুরোধের জন্য আপনার অবশ্যই টোকেন বা কাস্টম শিরোনাম (এবং যদি সম্ভব হয় উভয়ই) থাকতে হবে

— Yoni Jah

Answer 2

টি এল; ডিআর

একটি জেডাব্লুটি, যদি কুকিজ ব্যতীত ব্যবহৃত হয়, একটি সিএসআরএফ টোকেনের প্রয়োজনীয়তা উপেক্ষা করে - কিন্তু! সেশন / লোকালস্টোরজেজেডাব্লুটিটি সংরক্ষণ করে, আপনার সাইটে এক্সএসএস দুর্বলতা থাকলে (মোটামুটি সাধারণ) আপনার JWT এবং ব্যবহারকারীর পরিচয় প্রকাশ করুন। csrfTokenJWT- এ একটি কী যুক্ত করা এবং JWT টি একটি কুকিতে secureএবং http-onlyবৈশিষ্ট্যগুলি সেট সহ সঞ্চয় করা ভাল।

আরও তথ্যের জন্য একটি ভাল বর্ণনা দিয়ে এই নিবন্ধটি পড়ুন https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

আপনি xsrfToken JWT দাবী যুক্ত করে এই সিএসআরএফ সুরক্ষাটিকে রাষ্ট্রহীন করতে পারেন:

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

সুতরাং আপনাকে সিএসআরফটোকেন লোকালস্টোরেজ / সেশন স্টোরেজ পাশাপাশি জেডব্লিউটি নিজেই সংরক্ষণ করতে হবে (যা কেবলমাত্র একটি http- এবং নিরাপদ কুকিতে সঞ্চিত)। তারপরে সিএসআরএফ সুরক্ষার জন্য, যাডাব্লুটিটিতে সিএসআরএফ টোকেন জমা দেওয়া সিএসআরএফ-টোকেন শিরোনামের সাথে মেলে কিনা তা যাচাই করুন।

Comments

ব্যবহারকারীর এপিআই প্রমাণীকরণের সময় কি একজনকে সিএসআরএফ টোকেন ব্যবহার ছাড় দেওয়া উচিত?

— ব্যবহারকারী 805981

এটি উল্লেখ করার মতো (যেমন অন্যরা উত্সের লিঙ্কে মন্তব্যেও উল্লেখ করেছেন) যে কোনও সিএসআরএফ প্রশমন যা ক ব্যবহার করে) কুকিজ, যা কেবলমাত্র HTTP বা খ নয়) স্থানীয় স্টোরেজে সিএসআরএফ টোকেনকে এক্সএসএসের পক্ষে ঝুঁকিপূর্ণ। এর অর্থ হল যে উপস্থাপিত পদ্ধতিটি এক্সএসএস ব্যবহার করে আক্রমণকারী থেকে জেডাব্লুটিটিকে গোপন রাখতে সহায়তা করতে পারে তবে আক্রমণকারী এখনও আপনার এপিআইতে দূষিত অনুরোধটি কার্যকর করতে সক্ষম হবে কারণ তিনি একটি বৈধ জেডাব্লুটিটি সরবরাহ করতে সক্ষম (কুকির মাধ্যমে, আপনাকে ব্রাউজারকে ধন্যবাদ জানায়) এবং সিএসআরএফ টোকেন (স্থানীয় স্টোরেজ / কুকি থেকে ইনজেকশন জেএস এর মাধ্যমে পড়ুন)।

— জোহানেস রুডল্ফ

বাস্তবে এমনকি কোনও সিএসআরএফ টোকেন আপনাকে এক্সএসএসের এই স্তরেও সুরক্ষা দিতে পারে না, যেহেতু আপনি ধরে নিচ্ছেন যে আক্রমণকারী লোকালস্টোরারে অ্যাক্সেস করতে পারে, এটি বর্তমানে কেবলমাত্র স্ক্রিপ্ট স্তরের অ্যাক্সেস পাওয়া যায়, যা তারা যাইহোক সিএসআরএফ টোকেনটি দেখতে পারে ।

— অবৈধ

@ জোহনেস রুডল্ফ যা বলছিলেন তা কি নয়? আপনি ওয়েব স্টোরেজ / কেবলমাত্র নন-এইচপি-র কুকিতে সিএসআরএফ টোকেন সংরক্ষণ করার সাথে সাথে আপনি কোনও এক্সএসএস আক্রমণের আপনার পদচিহ্ন বাড়িয়ে তুলছেন কারণ সেগুলি জেএসের মাধ্যমে অ্যাক্সেসযোগ্য।

— অ্যাডাম-বেক

এখানে মোট বিশেষজ্ঞ নন, তবে আপনি যদি প্রথম দিকে যেমন এক্সএসএসের মুখোমুখি হয়ে থাকেন তবে আমি অবশ্যই নিশ্চিত নই যে অংশটি যুক্ত করা আরও ভাল ... সত্যই এটি ধারণ করে। সম্ভবত আক্রমণকারীর পক্ষে সিএসআরএফ টোকেন ধরে রাখা কিছুটা জটিল (?), তবে শেষ পর্যন্ত তিনি জেডব্লিউটি টোকেন না জেনেও আপনার পক্ষে অনুরোধটি সম্পাদন করতে সক্ষম হয়েছেন। এটা কি ঠিক? ধন্যবাদ

— সুপারজোজ 15