ওয়েব অ্যাপ কীভাবে চলে বুঝতে তার JavaScript পড়া

Front end বলে দেয় back end কীভাবে কাজ করে। Bundle করা JavaScript শান্তভাবে পড়া শিখুন এবং এটি অ্যাপের ডিজাইন সম্পর্কে কী দেখাতে পারে, জানুন।

কোড ও endpoint-এর তালিকাসহ একটি browser উইন্ডো

আধুনিক ওয়েব অ্যাপ আপনার browser-এ অনেক JavaScript পাঠায়। সেই কোড public, এবং এটি বলে দেয় অ্যাপ তার server-এর সাথে কীভাবে কথা বলে। নিরাপত্তা গবেষকের জন্য এটি অ্যাপের বিনামূল্যের মানচিত্র।

JavaScript কী বলে দিতে পারে

  • অ্যাপ যে API endpoint ও path ডাকে (/api/orders, /api/admin/users)।
  • Parameter ও request-এর গঠন: ফিল্ডের নাম, প্রত্যাশিত মান, লুকানো বিকল্প।
  • থাকলেও লিংক নেই এমন feature: admin পেজ, beta feature, API-র পুরোনো সংস্করণ।
  • Browser-এ করা role ও permission logic (লক্ষণ যে server হয়তো তা প্রয়োগ করে না)।
  • অ্যাপ যে তৃতীয় পক্ষের সেবার সাথে যুক্ত।
  • Client-side validation, যা আপনি server আসলে কী প্রয়োগ করে তার সাথে মেলাতে পারেন।

কীভাবে দেখবেন

  1. Browser developer tools-এর Sources ও Network ট্যাব খুলুন।
  2. প্রতিটি feature ক্লিক করে ঘুরতে Network ট্যাব ব্যবহার করুন। প্রতিটি request API কীভাবে কাজ করে তার একটি নথিভুক্ত উদাহরণ।
  3. লোড হওয়া .js ফাইল দেখুন। এগুলো প্রায়ই minified (ছোট নাম, এক লাইন)। ফরম্যাট করতে browser-এর "pretty print" বোতাম ব্যবহার করুন।
  4. ফাইলে api, fetch, axios, /v1/, admin, role, token-এর মতো শব্দ খুঁজুন।
  5. Source map (.js.map ফাইল) প্রকাশিত কি না দেখুন। থাকলে আসল পড়ার যোগ্য সোর্স পাওয়া যেতে পারে। বেশিরভাগ প্রোগ্রামে প্রোডাকশন source map নিজে vulnerability নয়, তাই policy দেখুন।

পড়ার সময় ভাবুন

  • কোন কাজ UI লুকায় কিন্তু API তবুও অনুমতি দিতে পারে? (সবসময় নিজের অ্যাকাউন্টে ও শুধু scope-এর ভেতরে পরীক্ষা করুন।)
  • Request-এ কি এমন ID আছে যা অন্য user-এর হতে পারে (authorization পরীক্ষার ইঙ্গিত)?
  • Front end কি এমন data বিশ্বাস করছে যা করা উচিত নয়, যেমন client থেকে পাঠানো role বা price ফিল্ড?
  • API-র সংস্করণ আছে কি, আর পুরোনোগুলো কি এখনও সক্রিয়?

JavaScript-এ secret

কখনো ডেভেলপাররা front-end কোডে API key, token বা অভ্যন্তরীণ URL রেখে দেয়। অনেক key public হওয়ার জন্যই (যেমন domain দিয়ে সীমিত maps key), তাই সাবধানে বিচার করুন। আসল private secret মনে হলে:

  • সিস্টেমে ঢুকতে এটি ব্যবহার করবেন না।
  • সচল কি না নিশ্চিত করার ন্যূনতমের বেশি পরীক্ষা করবেন না, এবং শুধু প্রোগ্রাম অনুমতি দিলে।
  • কোথায় পেয়েছেন ও কেন সংবেদনশীল তা জানিয়ে report করুন।

ভালো অভ্যাস

  • আকর্ষণীয় ফাইলের তারিখসহ কপি রাখুন, যাতে বদলের পর তুলনা করা যায়।
  • অ্যাপ আপডেট হলে diff দেখুন: নতুন কোড মানে প্রায়ই নতুন, অপরীক্ষিত feature।
  • যা পড়েন তা Network ট্যাবে যা দেখেন তার সাথে মেলান।

সীমা

কোড পড়া আক্রমণ নয়। Data বদলানো বা অন্য user-এর অ্যাকাউন্ট ছোঁয়া request পাঠানো হতে পারে। নিয়মের ভেতরে থাকুন, নিজের test অ্যাকাউন্ট ব্যবহার করুন এবং proof পেলে থামুন।

মূল কথা: front end একটি public নকশা। Endpoint ও ধারণা খুঁজতে মন দিয়ে পড়ুন, শুধু scope-এ নিজের অ্যাকাউন্টে পরীক্ষা করুন, আর আসল secret ব্যবহার না করে report করুন।


বাগ বাউন্টি সিরিজ, পর্ব ২ (recon ও টুল): 2 নম্বর (মোট 5)। আগের লেখা: Recon-এর গোড়া: নিয়ম না ভেঙে target-এর asset ম্যাপ করা.

আরও পড়ুন

দুটি অ্যাকাউন্ট দিয়ে API-র authorization bug পরীক্ষা

বেশিরভাগ গুরুতর API bug কে কী করতে পারে তা নিয়ে। সহজ matrix ও দুটি অ্যাকাউন্ট দিয়ে সাবধানে পরীক্ষা করুন এবং পরিষ্কারভাবে প্রমাণ করুন।

বাগ বাউন্টি•২ মিনিটে পড়া

Web archive ও public উৎস: ভুলে যাওয়া পেজ সঠিকভাবে খোঁজা

সাইট বদলায়, কিন্তু অতীত archive-এ থাকে। Public archive ও খোলা উৎস target বুঝতে কীভাবে সাহায্য করে এবং সীমারেখা কোথায়, জানুন।

বাগ বাউন্টি•২ মিনিটে পড়া

Burp Suite-এর গোড়া: proxy, repeater ও নিরাপদ পরীক্ষার ধারা

Burp Suite আপনার browser-এর পাঠানো request দেখতে ও বদলাতে দেয়। মূল টুল এবং আপনাকে scope-এ রাখে এমন শান্ত কাজের ধারা শিখুন।

বাগ বাউন্টি•২ মিনিটে পড়া