নিরাপদ সংযোগে লোড হওয়া পেজ যখন অনিরাপদ সংযোগে চাওয়া রিসোর্স ব্যবহার করে, তখন মিশ্র কনটেন্ট তৈরি হয়। Screpy-এর মিশ্র কনটেন্ট পরীক্ষক একটি পাবলিক HTTPS পেজের সোর্স HTML-এ HTTP রিসোর্স রেফারেন্স খুঁজে তার বিভাগ, ঠিকানা, প্রথম সোর্স লাইন ও উপস্থিতির সংখ্যা দেখায়। এই তথ্য দিয়ে পরিবর্তন দরকার এমন কনটেন্ট বা টেমপ্লেট খুঁজে নিরাপদ বিকল্প প্রস্তুত করতে পারেন।
রিপোর্ট পেজ চালায় না এবং তালিকাভুক্ত রিসোর্স আনে না। এটি অনুসন্ধানের জন্য সোর্স রেফারেন্স চিহ্নিত করে; দর্শকের ব্রাউজার আসলে কী লোড করেছে, HTTPS-এ নিয়েছে বা ব্লক করেছে তার রেকর্ড নয়। সফল পরীক্ষাও পুরো ওয়েবসাইটের নিরাপত্তা প্রত্যয়ন করে না।
রেফারেন্স থাকা HTTPS পেজটি পরীক্ষা করুন
যে পেজ দেখতে চান তার পূর্ণ পাবলিক ঠিকানা দিন। কোনো নিবন্ধের জন্য হোমপেজ বা সন্দেহজনক ছবির বদলে নিবন্ধের নিজস্ব URL দিন, যেমন উদাহরণ ঠিকানা https://example.com/guides/setup/। টুল দেওয়া একটি পেজ পরীক্ষা করে; ডোমেইনের সব পেজ খুঁজে বের করে না।
ইনপুটে HTTPS আবশ্যক। পরীক্ষার পরে চূড়ান্ত URL দেখুন, কারণ রিডাইরেক্ট পরীক্ষিত পেজ বদলে দিতে পারে। HTTPS ঠিকানা শেষে HTTP-তে পৌঁছালে HTTPS মিশ্র কনটেন্ট বিশ্লেষণ প্রযোজ্য নয়। এটি সমস্যামুক্ত ফলাফল নয়। অপ্রত্যাশিত গন্তব্য বুঝতে Redirect Checker ব্যবহার করুন।
পেজকে পাঠযোগ্য পাবলিক HTML দিতে হবে। লগইন স্ক্রিনে তার পেছনের ব্যক্তিগত পেজের চেয়ে আলাদা রেফারেন্স থাকতে পারে। অপ্রাপ্য রেসপন্স, অসমর্থিত ডকুমেন্ট বা ব্যর্থ অনুরোধের অর্থ চাওয়া পরীক্ষা অসম্পূর্ণ; এগুলো অনিরাপদ রেফারেন্স নেই বলে প্রমাণ করে না।
ব্লকযোগ্য রিসোর্স, আপগ্রেডের সম্ভাবনা ও ফর্মের গন্তব্য বুঝুন
টেবিল সীমিত করতে বিভাগ ফিল্টার ব্যবহার করুন, তারপর প্রতিটি ঠিকানার পাশের এলিমেন্ট ও অ্যাট্রিবিউট দেখুন। বিভাগগুলো টুল কীভাবে সমর্থিত HTTP রেফারেন্স গ্রুপ করে তা বোঝায়; এগুলো ব্রাউজারে পর্যবেক্ষণ করা ফল নয়।
| বিভাগ | এই রিপোর্টের উদাহরণ | কী তদন্ত করবেন |
|---|---|---|
| ব্লকযোগ্য, লাল | স্ক্রিপ্ট, স্টাইলশিট, ফ্রেম এবং রেসপনসিভ ছবির srcset বিকল্প |
সোর্স খুঁজে উপযুক্ত HTTPS বিকল্প নিশ্চিত করুন। |
| আপগ্রেডের সম্ভাবনা, হলুদ | সমর্থিত ছবি, অডিও ও ভিডিও সোর্স রেফারেন্স | কাঙ্ক্ষিত রিসোর্স সত্যিই HTTPS-এ কাজ করে কি না দেখুন; স্বয়ংক্রিয় আপগ্রেড প্রাপ্যতার প্রমাণ নয়। |
| অনিরাপদ ফর্মের গন্তব্য, কমলা | ফর্মের action বা বাটন/input-এর formaction |
ফর্ম বদলানোর আগে কাঙ্ক্ষিত নিরাপদ পাঠানোর ঠিকানা নিশ্চিত করুন। |
পরীক্ষক অবজেক্ট, ছবি-ধরনের ইনপুট, ভিডিও পোস্টার এবং নির্দিষ্ট link সম্পর্কের সমর্থিত রিসোর্স রেফারেন্সও দেখে। হোস্ট হিসেবে IP ঠিকানা থাকা ছবি বা মিডিয়া URL-কে আপগ্রেডের সম্ভাবনা না বলে ব্লকযোগ্য বিভাগে রাখা হয়।
মিশ্র কনটেন্টের বর্তমান নির্দেশনা আপগ্রেডযোগ্য ও ব্লকযোগ্য অনুরোধ আলাদা করে। প্রকৃত আচরণ ব্রাউজারের নিয়ম ও নিরাপত্তা নীতির ওপরও নির্ভর করে। সোর্সের এই শ্রেণিবিন্যাস সম্ভাব্য বিশ্বস্ত স্থানীয় ঠিকানাসহ সব ব্যতিক্রম মূল্যায়ন করে না। প্রতিটি লাল সারিকে নির্দিষ্ট ব্রাউজার অনুরোধ ব্লক করেছে তার প্রমাণ ধরবেন না।
ফর্মের গন্তব্য আলাদা পর্যালোচনার বিভাগ। মিশ্র কনটেন্ট স্পেসিফিকেশনের ফর্ম পাঠানোর অংশ ব্রাউজারের সতর্কতাকে সাধারণ রিসোর্স পরীক্ষা থেকে আলাদাভাবে আলোচনা করে। Screpy এসব ফর্ম পাঠায় না বা কী তথ্য সংগ্রহ করে তা নির্ধারণ করে না। যাচাই না করা গন্তব্যে সংবেদনশীল পরীক্ষার তথ্য না পাঠিয়ে আসল ফর্মের উদ্দেশ্য দেখুন।
গ্রুপ করা ফলাফল থেকে সোর্স খুঁজুন
একই এলিমেন্ট, অ্যাট্রিবিউট, শ্রেণিবিন্যাস ও রেজলভ করা URL-এর উপস্থিতিগুলো টেবিল একত্র করে। তাই একই ঠিকানা অন্য এলিমেন্ট বা অ্যাট্রিবিউটে আরেকটি সারি তৈরি করতে পারে। দেখানো লাইন হলো আনা HTML-এ গ্রুপটির প্রথম উপস্থিতি; টেমপ্লেট এডিটরের লাইনের সঙ্গে তা মিলতেই হবে এমন নয়।
এই কাল্পনিক অংশে চারটি HTTP রেফারেন্স আছে:
<script src="http://static.example.com/site.js"></script>
<img src="http://static.example.com/logo.png" alt="Example homepage">
<img src="http://static.example.com/logo.png" alt="Example homepage">
<form action="http://example.com/contact/" method="post"></form>
| গ্রুপ | উপস্থিতি | শ্রেণিবিন্যাস |
|---|---|---|
/site.js দিয়ে শেষ হওয়া script[src] |
1 | ব্লকযোগ্য |
/logo.png দিয়ে শেষ হওয়া img[src] |
2 | আপগ্রেডের সম্ভাবনা |
/contact/ দিয়ে শেষ হওয়া form[action] |
1 | অনিরাপদ ফর্মের গন্তব্য |
সারাংশে একটি ব্লকযোগ্য রেফারেন্স, দুটি আপগ্রেডের সম্ভাবনা এবং একটি ফর্ম রেফারেন্স গণনা হয়: তিন সারিতে চার উপস্থিতি। এর অর্থ চারটি আলাদা ফাইল বা নিশ্চিত চারটি নেটওয়ার্ক অনুরোধ নয়। উদাহরণটি রিপোর্টের গ্রুপিং বোঝায়; লাইভ স্ক্যান বা পূর্ণাঙ্গ কার্যকর যোগাযোগ ফর্ম নয়।
সংশ্লিষ্ট কনটেন্ট বা শেয়ার করা কম্পোনেন্টে পুনরাবৃত্ত রেফারেন্সের প্রতিটি উপস্থিতি খুঁজুন। শুধু প্রথম দেখানো লাইন ঠিক করলে অন্যটি অপরিবর্তিত থেকে যেতে পারে। কোন CMS ফিল্ড, থিম সেটিং বা টেমপ্লেট এটি তৈরি করে তা স্থির করার আগে ওই লাইনের আশপাশের আসল সোর্স দেখুন।
আপেক্ষিক পাথ বদলানোর আগে বেস URL দেখুন
দেখানো রিসোর্স URL ডকুমেন্টের কার্যকর বেসের বিপরীতে রেজলভ করা হয়। নিজস্ব বেস না থাকলে আপেক্ষিক পাথ চূড়ান্ত পেজ URL ব্যবহার করে। কিন্তু HTTP <base href> থাকলে পেজ HTTPS-এ আনা হলেও আপেক্ষিক রেফারেন্স HTTP-তে রেজলভ হতে পারে।
কাল্পনিক https://example.com/guides/setup/ পেজে এই অংশটি ভাবুন:
<head><base href="http://static.example.com/assets/"></head>
<body><img src="logo.png" alt="Example homepage"></body>
ছবিটি HTTPS পেজের ডিরেক্টরিতে নয়, http://static.example.com/assets/logo.png ঠিকানায় রেজলভ হয়। //static.example.com/assets/logo.png-এর মতো প্রোটোকল-আপেক্ষিক রেফারেন্সও বেসের স্কিম ব্যবহার করে। তাই শুধু http: মুছে ফেলা নিরাপদ গন্তব্য নিশ্চিত করে না।
HTML base-এর নির্দেশনা প্রথম প্রযোজ্য বেস কীভাবে আপেক্ষিক URL নিয়ন্ত্রণ করে তা ব্যাখ্যা করে। বেস ও কাঙ্ক্ষিত ফাইলের অবস্থান একসঙ্গে দেখুন। বেস বদলালে অন্য রিসোর্স, নেভিগেশন ও ফর্মের গন্তব্য বদলাতে পারে; প্রভাব না দেখে ইচ্ছাকৃত বেস সরাবেন না। স্পষ্টভাবে লেখা কার্যকর HTTPS রিসোর্স ঠিকানা কাঙ্ক্ষিত পরিবর্তনকে পরিষ্কার করতে পারে।
অনিরাপদ রেফারেন্সের বদলে কার্যকর HTTPS ঠিকানা দিন
যেখানে রেফারেন্স তৈরি হয় সেখান থেকে শুরু করুন। পুরোনো ছবির URL নিবন্ধের ফিল্ড, লোগোর সেটিং বা শেয়ার করা টেমপ্লেটে থাকতে পারে; এমবেড করা স্ক্রিপ্ট ইন্টিগ্রেশনের কোড থেকে আসতে পারে। পরের প্রকাশে ওভাররাইট হয়ে যাবে এমন তৈরি HTML-এর বদলে ওই উৎস ঠিক করুন। পুরো সাইটে সম্পর্কহীন http:// টেক্সট একসঙ্গে বদলানো এড়িয়ে চলুন।
ব্যবহারের আগে প্রস্তাবিত HTTPS ঠিকানা যাচাই করুন। অপ্রত্যাশিত রিডাইরেক্ট, প্রবেশাধিকার স্ক্রিন বা আলাদা কনটেন্টের বদলে কাঙ্ক্ষিত ছবি, স্ক্রিপ্ট বা রিসোর্স দিতে হবে। এই পরীক্ষক ওই অনুরোধ করেনি। হোস্ট একই ফাইল নিরাপদভাবে না দিলে http://static.example.com/site.js-কে HTTPS করা ব্যর্থ হতে পারে।
বাইরের কোনো নির্ভরতার উপযুক্ত নিরাপদ সংস্করণ না থাকলে সমর্থিত বিকল্প চান, অথবা ফিচারটি বাদ দেওয়া বা বদলানো দরকার কি না ঠিক করুন। শুধু ফলাফল সরাতে নিঃশব্দে সম্পর্কহীন ফাইল বসাবেন না। ফর্মের ক্ষেত্রে শুধু ঠিকানার বানান নয়, গ্রহণকারী এন্ডপয়েন্ট ও প্রত্যাশিত আচরণ যাচাই করুন।
upgrade-insecure-requests থাকা Content Security Policy সোর্সে HTTP রেফারেন্স রেখেই ব্রাউজারের অনুরোধ বদলাতে পারে। ডিরেকটিভের নির্দেশনা অনুযায়ী, অপ্রাপ্য HTTPS রিসোর্স HTTP-তে ফিরে না গিয়েই ব্যর্থ হতে পারে। এটি আপগ্রেড করা প্রতিটি রিসোর্স কাজ করে তার প্রমাণ নয়। ঘোষিত রেসপন্স হেডার আলাদা দেখতে HTTP Headers Checker ব্যবহার করুন; বিদ্যমান নীতি না বুঝে বদলাবেন না বা সমস্যা লুকাতে ব্রাউজারের সুরক্ষা বন্ধ করবেন না।
প্রকাশিত সোর্স ও ব্রাউজারের অনুরোধ দুটিই যাচাই করুন
পরিবর্তনের আগে প্রথম রিপোর্ট ও কাঙ্ক্ষিত বিকল্প একসঙ্গে সংরক্ষণ করুন। JSON ডাউনলোডে রাখা ফলাফল ও গ্রুপ থাকে; বিভাগ বাছাই টেবিল বদলায়, সম্পূর্ণ রিপোর্টের ডাউনলোড নয়। এই টুলে CSV রপ্তানি বা স্বয়ংক্রিয় সংশোধন নেই।
- সংশোধিত কনটেন্ট, সেটিং বা টেমপ্লেট প্রকাশ করুন; আপডেট হওয়া রেসপন্স পাওয়া গেলে একই HTTPS পেজ আবার পরীক্ষা করুন।
- সংশ্লিষ্ট URL, এলিমেন্ট, অ্যাট্রিবিউট ও উপস্থিতির সংখ্যা তুলনা করুন। কমে যাওয়া মোট সংখ্যা অন্য কোনো রেফারেন্স বাকি থাকার বিষয় লুকাতে পারে; শুধু সারাংশ নয়, সারিগুলোও দেখুন।
- পেজ ব্রাউজারে খুলে ডেভেলপার কনসোলের সতর্কতা ও নেটওয়ার্ক অনুরোধ দেখুন। সংশ্লিষ্ট ছবি, মিডিয়া বা ফিচার ব্যবহার করুন; সোর্স রিপোর্ট এসব ইন্টারঅ্যাকশন চালায় না।
- একই পরিবর্তিত টেমপ্লেটের অন্য পেজও পরীক্ষা করুন। হোমপেজ ঠিক হওয়া মানে প্রতিটি পণ্য বা নিবন্ধ ঠিক হয়েছে নয়।
Chrome-এর নিরাপত্তা প্যানেলের নির্দেশনা অনিরাপদ origin থেকে সংশ্লিষ্ট নেটওয়ার্ক অনুরোধে যাওয়ার পদ্ধতি দেখায়। ব্রাউজারের পর্যবেক্ষণ স্ক্রিপ্ট বা স্টাইলের তৈরি এমন অনুরোধ দেখাতে পারে যা এই সোর্স-ভিত্তিক টুল দেখে না। আসল সোর্সে HTTP থাকলেও আপগ্রেড বা ব্লক হওয়া অনুরোধও দেখাতে পারে।
এই পর্যবেক্ষণ আলাদা রাখুন: সংশোধিত সোর্স রেফারেন্স এবং সফল ব্রাউজার অনুরোধ আলাদা প্রশ্নের উত্তর। কোনোটিই একা সব কনটেন্ট, প্রতিটি ব্রাউজার বা পুরো ওয়েবসাইট নিরাপদ প্রমাণ করে না।
ফলাফল না পাওয়া ও আংশিক কভারেজ বুঝুন
পরীক্ষক সর্বোচ্চ 2 MiB HTML গ্রহণ করে এবং ২০০ গ্রুপ করা সারিতে সর্বোচ্চ ১,০০০ HTTP রেফারেন্স রাখে। ফলাফলের সীমায় আরও তথ্য রাখা না গেলে কভারেজ আংশিক হয় এবং সম্পূর্ণ রেফারেন্স সংখ্যা অজানা থাকে। সারাংশ তখন পুরো ডকুমেন্ট নয়, রাখা অংশ বোঝায়। সোর্স আনা না গেলে বা HTML-এর সীমা ছাড়ালে চাওয়া পরীক্ষা বরং অপ্রাপ্য থাকে।
কোনো ফলাফল নেই মানে পরীক্ষিত সোর্সের আওতায় সমর্থিত HTTP রেফারেন্স পাওয়া যায়নি। এটি JavaScript-এর তৈরি অনুরোধ, CSS url() মান, বাইরের স্টাইলশিটের কনটেন্ট, ভেতরের ফ্রেম ডকুমেন্ট বা সম্ভাব্য সব অ্যাট্রিবিউট অন্তর্ভুক্ত করে না। রিসোর্সের রিডাইরেক্টও অনুসরণ করে না: প্রথম HTTPS অ্যাট্রিবিউট পড়ে পরে HTTP-তে রিডাইরেক্ট হয় কি না স্থির করা যায় না।
সাধারণ নেভিগেশন অ্যাঙ্কর বাদ থাকে, HTTP পেজের সাধারণ লিংকও এর মধ্যে পড়ে। ডাউনলোডের আচরণ ও গন্তব্যের নিরাপত্তা আলাদা পরীক্ষা দরকার; টেবিলে অনুপস্থিত থাকা অনুমোদন নয়। এমবেড করা রিসোর্সের বদলে পেজের বেরিয়ে যাওয়া লিংক সম্পর্কে প্রশ্ন হলে Internal Link Analyzer ব্যবহার করুন।
আংশিক রিপোর্টের আওতা JSON ডাউনলোডে রাখুন এবং বাকি সোর্স রেফারেন্স আলাদাভাবে দেখুন। দেখানো সারি সরানো মানে বাদ পড়া রেফারেন্সও ঠিক হয়েছে নয়। পরিবর্তনের পরে আবার চালান এবং নিশ্চিত সংশোধনকে কখনো পরীক্ষা না হওয়া তথ্য থেকে আলাদা করতে পুরোনো রিপোর্ট রাখুন।