ওয়েবসকেটগুলির জন্য কেন সম-উত্স নীতি নেই? আমি কেন ডাব্লুএস: // লোকালহোস্টের সাথে সংযোগ রাখতে পারি?

Question

আমি আমার অ্যাপ্লিকেশনটির জন্য আন্তঃ-প্রক্রিয়া যোগাযোগের জন্য ওয়েবসকেটগুলি ব্যবহার করতে চাই (ডেমন <-> ওয়েবজিইউআই এবং ডেমন <-> ফ্যাটক্লিয়েন্ট ইত্যাদি)। পরীক্ষার সময়, আমি আমার স্থানীয়ভাবে চলমান ওয়েব সকেট সার্ভারের সাথে সংযুক্ত করার চেষ্টা করেছি (ডাব্লুএস: // লোকালহোস্ট: 1234) জাভাস্ক্রিপ্ট ওয়েবসকেট ক্লায়েন্টের মাধ্যমে ওয়েবসকেট.আর ( http://www.websocket.org/echo.html ) এর মাধ্যমে।

আমার প্রশ্ন এখন:
কেন এটি সম্ভব? ব্রাউজারগুলিতে কি কোনও ক্রস-আদি নীতি প্রয়োগ করা হয়নি (এখানে: লিনাক্সে এফএফ 29)?

আমি জিজ্ঞাসা করছি কারণ যদি ওয়েবসকেট.অর্গটি মন্দ ছিল তবে এটি আমার স্থানীয় ডাব্লুএস সার্ভারের সাথে যোগাযোগের চেষ্টা করতে পারে এবং স্থানীয় হোস্ট থেকে প্রাপ্ত প্রতিটি বার্তা অন্য কোনও সার্ভারে পুনর্নির্দেশ করতে পারে:

স্থানীয় ওয়েবস্কট সার্ভার ব্রাউজার এভিল ওয়েব সার্ভার
at ডাব্লুএস: // লোকালহোস্ট: 1234 এ HTTP: //evil.tld
        | | |
        | | ------ [জিইটি /] ---------> |
        | | <----- [এইচটিএমএল + এভিলজেএস] ---- |
        | <------ [সংযুক্ত ws: // ..] ---- | | |
        | <---- [কিছু যোগাযোগ] -> | |
        | | ---- [দুষ্টু এগিয়ে] ----> |
        | | |

আমি পুরো ব্যবহারের কেসটি পরীক্ষা করে দেখিনি, তবে ওয়েবসকেট.অর্গ.আর দ্বারা সরবরাহিত জেএস থেকে ডাব্লুএস: // লোকালহোস্টের সাথে সংযোগ অবশ্যই কাজ করে।

Comments

— ওয়েবসকেট.অর্গটি

Answer 1

"কেন?" অংশ হিসাবে, ব্রাউজাররা এজাক্স কলগুলির বিপরীতে ওয়েবসকেটগুলির জন্য একই উত্স নীতি (যার মধ্যে সিওআরএস একটি শিথিলকরণ) প্রয়োগ করে না, কারণ ক্রম-উত্স অনুরোধগুলির মান প্রতিষ্ঠিত হওয়ার পরে ওয়েবসকেট চালু হয়েছিল এবং কারণ তারা ' শুরু করার জন্য এসওপির সাপেক্ষে নয়, সিওআরএস ক্লায়েন্ট-সাইড চেকের historicalতিহাসিক কারণ প্রযোজ্য নয়।

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

যদি ওয়েবটি আজ আবিষ্কার করা হচ্ছিল, আমরা এখন কী জানি তা জেনেও, এজ্যাক্সের জন্য এসওপি বা সিওআরএসের প্রয়োজন পড়বে না এবং এটি সম্ভব হয় যে সমস্ত বৈধতা সার্ভারে রেখে দেওয়া হবে।

ওয়েবসকেটগুলি, একটি নতুন প্রযুক্তি হওয়ায় ক্রস-ডোমেনের দৃশ্যপটটিকে সমর্থন করার জন্য ডিজাইন করা হয়েছে। সার্ভার যুক্তি লেখার যে কোনও ব্যক্তিকে ভারী-হাতের ব্রাউজারের সাবধানতা প্রয়োজন ছাড়াই ক্রস-অরিজিন অনুরোধগুলির সম্ভাবনা সম্পর্কে সচেতন হওয়া উচিত এবং প্রয়োজনীয় বৈধতা দেওয়া উচিত à লা সিওএস C

---

¹ এটি সরলকরণ। উত্সের জন্য ক্রস-অরিজিন্ট জিইটি অনুরোধগুলি (<img>, <লিঙ্ক> এবং <script> ট্যাগ সহ) এবং ফর্ম জমা দেওয়ার পোস্টের অনুরোধগুলি সর্বদা ওয়েবে একটি মৌলিক বৈশিষ্ট্য হিসাবে অনুমোদিত ছিল। আজকাল, ক্রস-অরিজিন এজেএক্স কলগুলির অনুরোধগুলির অনুরূপ বৈশিষ্ট্যগুলিও অনুমোদিত এবং সাধারণ ক্রস-অরিজিন অনুরোধ হিসাবে পরিচিত । যাইহোক, কোডটিতে যেমন অনুরোধগুলি থেকে ফিরে আসা ডেটা অ্যাক্সেসের অনুমতি দেওয়া হয় না যদি না সার্ভারের সিওআরএস শিরোলেখ দ্বারা সুস্পষ্টভাবে অনুমতি দেওয়া হয়। এছাড়াও, এই "সহজ" পোষ্ট অনুরোধগুলি হ'ল সার্ভারগুলির জন্য দূষিত ওয়েবসাইটগুলি থেকে তাদের সুরক্ষিত করার জন্য বিরোধী সিএসআরএফ টোকেনের প্রয়োজনীয় কারণ এটি প্রাথমিক কারণ।

² প্রকৃতপক্ষে, অনুরোধ উত্সটি যাচাই করার জন্য একটি সুরক্ষিত Refererউপায়ও পাওয়া যায় নি যেহেতু শিরোনামটি স্পোফ করা যায় যেমন একটি উন্মুক্ত পুনর্নির্দেশ দুর্বলতা ব্যবহার করে। এটি সিএসআরএফ দুর্বলতাগুলি ততক্ষণে বুঝতে পেরেছিল তাও দেখায়।

Comments

এটি প্রকৃতপক্ষে প্রশ্নের উত্তর দেয়, সুতরাং +1। তবে, রেকর্ডটির জন্য, আমি এই যুক্তির সাথে দৃ strongly়ভাবে একমত নই। আমি পূর্বাভাস দিয়েছি যে এই ডিজাইনের সিদ্ধান্তের ফলস্বরূপ, ওয়েবসকেট ব্যবহার করা উল্লেখযোগ্য সংখ্যক সাইটগুলি শিরোনামকে বৈধতা দিতে Originএবং ফলস্বরূপ তৃতীয় পক্ষের সাইটগুলিতে ব্যক্তিগত ব্যবহারকারীর ডেটা ফাঁস করতে ব্যর্থ হবে । ওয়েডে Access-Control-Allow-Originঅন্য কোনও ক্রস-আদি HTTP অনুরোধের প্রতিক্রিয়াগুলিতে জেএসকে অ্যাক্সেসের অনুমতি দেওয়ার আগে শিরোনামটি যাচাই করছেন গ্রাহকরা , আক্রমণটির এই পুরো শ্রেণীর (ক্রস-সাইট ওয়েবসকেট হাইজ্যাকিং) প্রতিরোধের একটি সহজ উপায় হতে পারে। খুব দেরি হয়ে গেছে এখন.

— আজেদি 32

আমি সম্মত হতে আগ্রহী, ডিজাইনের পরিবর্তনটি মূলত একটি শ্বেতলিস্ট-ভিত্তিক পদ্ধতির থেকে একটি কালো তালিকাভুক্তের দিকে চলে যা ঝুঁকিপূর্ণ। ন্যায্য বিন্দু.

— staafl

Answer 2

oberstet প্রশ্নের উত্তর । ধন্যবাদ! দুর্ভাগ্যক্রমে আমি এটিকে "সঠিক" হিসাবে চিহ্নিত করতে পারি না কারণ এটি একটি মন্তব্য ছিল। ব্রাউজারটি "মূল" শিরোনাম প্রেরণ করে যা অ্যাপ্লিকেশন দ্বারা চেক করা যেতে পারে।

জাভাতে [1]:

@অগ্রাহ্য করা
ওপেন পাবলিক অকার্যকর (ওয়েবস্কট ক্লায়েন্টসকেট, ক্লায়েন্টহ্যান্ডশেক হ্যান্ডশেক) {
    স্ট্রিং ক্লায়েন্টআরগিন = হ্যান্ডশেক.জেটফিল্ডভ্যালু ("উত্স");

    যদি (ক্লায়েন্টঅরগিন == নাল ||
        logger.log (স্তর। সতর্কতা, "ক্লায়েন্ট সঠিক উত্স শিরোনাম প্রেরণ করেনি:" + ক্লায়েন্টআরগিন);        

        ক্লায়েন্টসকেট.ক্লোজ ();
        প্রত্যাবর্তন
    }

    // ...
}

[1] https://github.com/TooTallNate/ জাভা- ওয়েবসকেট ব্যবহার করে

Comments

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

— কেভিন সেক্রিস্ট

Answer 3

ওয়েবসকেটগুলি ডোমেন যোগাযোগ অতিক্রম করতে পারে এবং সেগুলি এসওপি (একই উত্স নীতি) দ্বারা সীমাবদ্ধ নয়।

আপনি বর্ণিত একই সুরক্ষা সমস্যাটি ওয়েবসকেট ছাড়াই ঘটতে পারে।

দুষ্ট জেএস পারেন:

• খারাপ.tld এর URL সহ একটি স্ক্রিপ্ট / চিত্র ট্যাগ তৈরি করুন এবং কোয়েরি স্ট্রিংয়ে ডেটা রাখুন।
• একটি ফর্ম ট্যাগ তৈরি করুন, ক্ষেত্রগুলিতে ডেটা রাখুন, এবং এইচটিটিপি পোস্ট করে ফর্মের "জমা দিন" পদক্ষেপের অনুরোধ করুন, এটি ক্রস ডোমেন হতে পারে। AJAX এসওপি দ্বারা সীমাবদ্ধ, তবে সাধারণ HTTP পোষ্ট হয় না। এক্সএসআরএফ ওয়েব সুরক্ষা সমস্যাটি পরীক্ষা করুন Check

যদি আপনার পৃষ্ঠায় জাভাস্ক্রিপ্টকে কোনও কিছু সংক্রামিত করে বা আপনি দূষিত জাভাস্ক্রিপ্ট পান তবে আপনার সুরক্ষা ইতিমধ্যে ভঙ্গ হয়ে গেছে।

Comments

আমি খারাপ জেএস সম্পর্কে উদ্বিগ্ন নই। আমি জানি যে এটি সর্বদা সম্ভব। ব্রাউজার ব্রেক-আউট: যা সম্পর্কে আমি সত্যিই উদ্বিগ্ন: যে কোনও ওয়েবসাইট এখন স্থানীয়ভাবে আবদ্ধ WS সকেটের সাথে যোগাযোগ করতে পারে এবং সেখান থেকে ডেটা চুরি করতে পারে।

— বিনউইডারহির

এসওপি / সিওআরএস ওয়েবস্কটে প্রয়োগ হয় না, তবে ব্রাউজারগুলি originএমন শিরোনাম প্রেরণ করবে যাতে সার্ভারের হোস্টনামটি জেএসের সাথে এইচটিএমএল পরিবেশন করে যা ওয়েবস্কট সংযোগটি খোলে। একটি ওয়েবস্কট সার্ভার তারপরে চেক করে অ্যাক্সেসকে সীমাবদ্ধ করতে পারে origin।

— oberstet

এটি প্রশ্নের উত্তর দেয় না। প্রশ্নটি হ'ল কেন অন্য ডোমেনের একটি ওয়েবপৃষ্ঠা একটি স্থানীয় ওয়েবস্ককে অ্যাক্সেস করতে পারে। ওপিএসের দৃশ্যে এমন কিছুই নেই যা "আপনার পৃষ্ঠায় জাভাস্ক্রিপ্ট সংক্রামিত করে" - এটি একটি ভিন্ন দৃশ্য। ওয়েবসকেট ব্যতীত, একটি দূরবর্তী ওয়েবপৃষ্ঠা লোকালহোস্টের সংস্থানগুলি পড়তে সক্ষম হবে না, কারণ এটি স্পষ্টতই এসওপি প্রতিরোধ করে।

— sleske