দ্রুত triage হওয়া bug bounty report কীভাবে লিখবেন
দুজন গবেষক একই bug পেয়েও report-এর কারণে আলাদা ফল পেতে পারেন। পরিষ্কার, দ্রুত-যাচাইযোগ্য ও পেশাদার হতে এই template ব্যবহার করুন।
Triage বিশ্লেষকরা প্রতিদিন অনেক report পড়েন। যে report বুঝতে ও reproduce করতে সহজ, তা দ্রুত গৃহীত হয় এবং সঠিকভাবে রেট হওয়ার সম্ভাবনা বেশি।
Template
১. Title। নির্দিষ্ট ও ছোট। কী এবং কোথায় বলুন।
- দুর্বল: "XSS পাওয়া গেছে"
- ভালো: "/blog/{id}-এর comment ফিল্ডে Stored XSS অন্য user-দের browser-এ script চালাতে দেয়"
২. সারাংশ। দুই-তিন বাক্য: bug কী, কোথায়, এবং আক্রমণকারী এর মাধ্যমে কী করতে পারে।
৩. প্রভাবিত asset ও scope। সঠিক URL, endpoint বা অ্যাপ, এবং এটি scope-এ থাকার নিশ্চিতকরণ। প্রাসঙ্গিক হলে পরিবেশ ও সংস্করণ দিন।
৪. Reproduce-এর ধাপ। নম্বরযুক্ত, সঠিক ও সম্পূর্ণ, নতুন অবস্থা থেকে:
- দুটি test অ্যাকাউন্ট A ও B বানান।
- A হিসেবে login করে
/invoices/1001খুলুন। - ID বদলে
1002দিন (B-র invoice)। - দেখুন B-র invoice 200 status-সহ ফেরত এসেছে।
সঠিক request (HTTP request ও response-এর কপি), parameter ও দরকারি header দিন। যে bug কখনো দেখেনি সে কয়েক মিনিটে reproduce করতে পারবে।
৫. Proof of concept। Screenshot, ছোট ভিডিও বা log। শুধু নিরীহ proof ব্যবহার করুন (যেমন আসল user-দের নয়, আপনার নিজের দ্বিতীয় test অ্যাকাউন্টের data দেখানো)।
৬. প্রভাব। ব্যাখ্যা করুন user বা ব্যবসার বাস্তবে কী হতে পারে: data প্রকাশ, account দখল, আর্থিক ক্ষতি। তথ্যভিত্তিক থাকুন, বাড়িয়ে বলবেন না। কী করেননি তাও বলুন (আসল user-এর data দেখেননি)।
৭. Severity পরামর্শ। সংক্ষিপ্ত কারণসহ একটি রেটিং দিন, আদর্শভাবে প্রোগ্রামের স্কেল বা CVSS ব্যবহার করে। Triage বদলাতে পারে।
৮. সমাধানের পরামর্শ। এক-দুই লাইন, যেমন "server-এ যাচাই করুন invoice বর্তমান user-এর কি না"। এটি ইঞ্জিনিয়ারদের সাহায্য করে এবং বোঝা দেখায়।
৯. অতিরিক্ত প্রসঙ্গ। একই ত্রুটির সম্পর্কিত endpoint, browser বা টুলের সংস্করণ, এবং আপনার পরীক্ষার সময়, যদি log দেখা হয়।
Report বন্ধ হওয়ার সাধারণ ভুল
- প্রভাব না থাকা: কেন গুরুত্বপূর্ণ তা না দেখিয়ে "আমি এই header বদলাতে পারি"।
- যাচাই ছাড়া scanner output report হিসেবে পেস্ট করা।
- কোনো কাজের proof ছাড়া তাত্ত্বিক সমস্যা।
- Scope-এর বাইরে বা বাদ দেওয়া findings (বাদ দেওয়ার তালিকা পড়ুন)।
- "পেজে গিয়ে payload ঢোকান"-এর মতো অস্পষ্ট ধাপ।
- বাড়িয়ে বলা severity, যা আস্থা নষ্ট করে।
- একই report-এ কয়েকটি সম্পর্কহীন bug। আলাদা জমা দিন।
- অনুমতির আগে public প্রকাশ।
- Comment-এ রূঢ় বা চাপ দেওয়ার সুর।
Triage-এর সময় ও পরে
- প্রশ্নের দ্রুত ও ভদ্রভাবে উত্তর দিন।
- আরও proof চাইলে নিরাপদে দিন।
- Informative বা not applicable বলে বন্ধ হলে কারণ পড়ুন, শিখুন, এগিয়ে যান। নতুন প্রমাণ নিয়ে সম্মানের সাথে দ্বিমত করুন, বারবার দাবি নয়।
- বলা হলে fix আবার পরীক্ষা করুন।
জমা দেওয়ার আগে ছোট checklist
- অপরিচিত কেউ কি শুধু আমার ধাপ থেকে reproduce করতে পারবে?
- আমি কি আসল, বাস্তবসম্মত প্রভাব দেখিয়েছি?
- আমি কি scope-এ থেকেছি এবং আসল user-দের data ছুঁইনি?
- Title কি নির্দিষ্ট?
মূল কথা: ভালো report নির্দিষ্ট, reproduce-যোগ্য, প্রভাব নিয়ে সৎ এবং ভদ্র। প্রতিবার template ব্যবহার করুন।
বাগ বাউন্টি সিরিজ, পর্ব ১ (শুরু করা): 3 নম্বর (মোট 4)। আগের লেখা: Bug bounty platform: কোথা থেকে শুরু করবেন.
