এই নতুন এএসপি.এনইটি সুরক্ষার দুর্বলতা কতটা গুরুতর এবং আমি কীভাবে এটিকে কাজে লাগাতে পারি?


189

আমি এএসপি.এনইটি-তে নতুন সন্ধান করা সুরক্ষিত দুর্বলতার বিষয়ে নেটটিতে পড়েছি। আপনি বিশদটি এখানে পড়তে পারেন।

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

এটি কিছুটা অস্পষ্ট তবে এখানে আরও ভয়ঙ্কর একটি অংশ রয়েছে:

আক্রমণটির প্রথম পর্যায়ে কয়েক হাজার অনুরোধ লাগে, তবে একবার এটি সফল হয় এবং আক্রমণকারী গোপন কীগুলি পেয়ে গেলে এটি পুরোপুরি চৌকস।

সর্বোপরি, আমি সত্যই এটি গুরুতর কিনা তা জানার জন্য সুরক্ষা / ক্রিপ্টোগ্রাফি বিষয়টির সাথে যথেষ্ট পরিচিত নই।

সুতরাং, সমস্ত এএসপি.এনইটি বিকাশকারীদের কি এই কৌশলটি ভয় করা উচিত যা কোনও এএসপি.এনইটি ওয়েবসাইট সেকেন্ডের মধ্যে থাকতে পারে বা কী?

এই সমস্যাটি কীভাবে গড় ASP.NET বিকাশকারীকে প্রভাবিত করে? এটি কি আদৌ আমাদের প্রভাবিত করে? বাস্তব জীবনে এই দুর্বলতার পরিণতি কী? এবং, অবশেষে: এমন কিছু কাজ আছে যা এই দুর্বলতাটিকে বাধা দেয়?

আপনার উত্তরের জন্য ধন্যবাদ!


সম্পাদনা: আমার প্রতিক্রিয়াগুলি সংক্ষেপে বলি

সুতরাং, এটি মূলত একটি "প্যাডিং ওরাকল" ধরণের আক্রমণ। এই ধরণের আক্রমণটির অর্থ কী তা সম্পর্কে @ শ্রী একটি দুর্দান্ত ব্যাখ্যা দিয়েছিল। সমস্যাটি সম্পর্কে একটি চমকপ্রদ ভিডিও এখানে!

এই দুর্বলতার গুরুতরতা সম্পর্কে: হ্যাঁ, এটি সত্যই গুরুতর। এটি আক্রমণকারীটিকে একটি অ্যাপ্লিকেশনের মেশিন কীটি জানতে দেয়। সুতরাং, তিনি খুব অযাচিত কিছু করতে পারেন ।

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

এখানে ভাল অনুশীলন আমি পেয়েছিলাম যে একটি গুচ্ছ হয় না সমস্যা সমাধানের কিন্তু সাহায্যের একটি ওয়েব অ্যাপ্লিকেশন সাধারণ নিরাপত্তা উন্নত।

এখন, এই ইস্যুতে ফোকাস করা যাক।

সমাধান

  • কাস্টমআরিয়ারগুলি সক্ষম করুন এবং একটি ত্রুটি পৃষ্ঠা তৈরি করুন যাতে সমস্ত ত্রুটিগুলি পুনঃনির্দেশিত হয়। হ্যাঁ, এমনকি 404s । (স্কটগু বলেছিলেন যে এই আক্রমণটির জন্য 404 এবং 500 এর মধ্যে পার্থক্য করা অত্যাবশ্যক)) এছাড়াও আপনার Application_Errorবা Error.aspxএমন কোনও কোড রাখুন যা এলোমেলো দেরি করে। (একটি এলোমেলো সংখ্যা উত্পন্ন করুন এবং থ্রেডটি ব্যবহার করুন that দীর্ঘক্ষণ ঘুমানোর জন্য ঘুমান)) আক্রমণকারীটির পক্ষে আপনার সার্ভারে ঠিক কী ঘটেছে তা সিদ্ধান্ত নেওয়া অসম্ভব হয়ে উঠবে।
  • কিছু লোক 3DES এ ফিরে যাওয়ার প্রস্তাব দেয়। তত্ত্ব অনুসারে, আপনি যদি এইএস ব্যবহার না করেন তবে আপনি এইএস প্রয়োগের ক্ষেত্রে সুরক্ষা দুর্বলতার মুখোমুখি হন না। দেখা যাচ্ছে যে এটি মোটেই সুপারিশ করা হয় না

অন্য কিছু চিন্তা

  • মনে হচ্ছে যে না সবাই মনে করে কার্যসংক্রান্ত ভাল যথেষ্ট।

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


12
ভেনেমো, আমি কী বলতে পারি যে আমি এই অনুরোধের জন্য উত্তম জায়গা বলে মনে করি না (উত্তরগুলি বিচার করে)। এই প্রশ্নটি সমাধান করার পক্ষে ভোট দেওয়া ভাল উপায় নয়, এটির একটি বিশেষজ্ঞের দ্বারা জবাব দেওয়া দরকার (এবং ভোট দেওয়ার জন্য আপনাকে বিশেষজ্ঞ হওয়ার দরকার নেই)। আমি প্রস্তাব দিচ্ছি: mail-archive.com/cryptography@metzdowd.com/maillist.html বা, নীচের কেউ যেমন উল্লেখ করেছেন, মাইক্রোসফ্ট থেকে সরকারী মন্তব্য, যা ক্লায়েন্টকে কোনও ত্রুটি বার্তা না প্রেরণ করবে। এটি সঠিক পদ্ধতির। 3DES এ ডাউনগ্রেড করবেন না। এটি মর্মাহত পরামর্শ।
দুপুর সিল্ক

2
এমএস থেকে আরও: ব্লগস.টেকনেট.com
b

3
@ RPM1984 - আমি সম্মত নই। এখানে প্রচুর ব্যবহারযোগ্য প্রতিক্রিয়া রয়েছে। @ ডান, কেন?
ভেনেমো

2
ঠিক আছে, আমাদের কাছে এসও সম্পর্কিত একটি প্রশ্নের বিভিন্ন ব্যাখ্যা রয়েছে। আমার কাছে, যদি এটির সঠিক উত্তর দেওয়া যায় তবে ঠিক আছে। উত্তরগুলি আকর্ষণীয় / সহায়ক, আমাকে ভুল বুঝবেন না, তবে এটি আমার কাছে একটি বিষয় যেখানে একমাত্র "উত্তর" হ'ল কার্যতঃ - যতক্ষণ না এমএস কোনও সমাধান ছাড়েন। আমার কাছে এটি উইকি হওয়া উচিত।
RPM1984

4
যদি কেউ এই থ্রেডটিতে সুরক্ষা ফিক্সটি খুঁজতে ফিরে আসে, তারা মাইক্রোসফট / টেকনেট / সুরক্ষা / বুলেটিন / এমএস 10-070.mspx (আপনার OS এবং .NET সংস্করণ চয়ন করুন) এ অবস্থিত।
অ্যান্ডি

উত্তর:


58

নিজেকে রক্ষা করতে আমার কী করা উচিত?

[আপডেট 2010-09-29]

মাইক্রোসফ্ট সুরক্ষা বুলেটিন

ফিক্সের রেফারেন্স সহ কেবি আর্টিকেল

স্কটগু ডাউনলোডগুলির জন্য লিঙ্ক আছে

[আপডেট 2010-09-25]

আমরা যখন ঠিক করার অপেক্ষায় রয়েছি , গতকাল স্কটগু কাস্টম ইউআরএলস্ক্যান নিয়ম দিয়ে কীভাবে আপনার সাইটগুলিকে সুরক্ষিত করতে অতিরিক্ত পদক্ষেপ যুক্ত করতে পারে তার একটি আপডেট পোস্ট করেছে।


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

আক্রমণকারীকে যোগ করা আক্রমণ সম্পর্কিত তথ্যের প্রতিক্রিয়া নির্ধারণের সময় থেকে আটকাতে ত্রুটি পৃষ্ঠায় এলোমেলোভাবে সময় জুড়ে দিন।

ওয়েবকনফিগে In

<configuration>
 <location allowOverride="false">
   <system.web>
     <customErrors mode="On" defaultRedirect="~/error.html" />
   </system.web>
 </location>
</configuration>

এটি কোনও 200 স্ট্যাটাস কোডের সাথে ফিরে আসা কোনও কাস্টম পৃষ্ঠায় কোনও ত্রুটি পুনর্নির্দেশ করবে। এইভাবে কোনও আক্রমণকারী ত্রুটি কোড বা ত্রুটি সম্পর্কিত তথ্যের জন্য পরবর্তী আক্রমণগুলির জন্য প্রয়োজনীয় তথ্যের জন্য তাকাতে পারে না।

এটি সেট করাও নিরাপদ customErrors mode="RemoteOnly", কারণ এটি "বাস্তব" ক্লায়েন্টদের পুনর্নির্দেশ করবে। শুধুমাত্র লোকালহোস্ট থেকে ব্রাউজ করা অভ্যন্তরীণ। নেট ত্রুটিগুলি দেখায়।

গুরুত্বপূর্ণ অংশটি হ'ল সমস্ত ত্রুটি একই ত্রুটি পৃষ্ঠাটি ফিরে আসার জন্য কনফিগার করা হয়েছে তা নিশ্চিত করা। এই আপনি স্পষ্টভাবে সেট করতে প্রয়োজন defaultRedirectউপর অ্যাট্রিবিউট <customErrors>বিভাগে এবং নিশ্চিত করুন যে কোন প্রতি-স্থিতি কোডগুলি সেট করা হয়।

কি ঝুঁকির?

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

রেফারেন্স লিঙ্ক

দুর্বলতা সম্পর্কে মাইক্রোসফ্টের অফিসিয়াল মন্তব্য পড়ুন http://www.microsoft.com/technet/security/advisory/2416728.mspx । এই ইস্যুতে বাস্তবায়নের বিশদটির জন্য বিশেষত "ওয়ার্কআরাউন্ড" অংশ।

আপনার ওয়েব সার্ভারে দুর্বল এএসপি . নেট অ্যাপ্লিকেশনগুলি সন্ধানের জন্য স্ক্রিপ্ট সহ স্কটগু ব্লগে কিছু তথ্য ।

"প্যাডিং ওরাকল আক্রমণগুলি বোঝার" বিষয়ে একটি ব্যাখ্যার জন্য, @ এসআর এর উত্তরটি পড়ুন


নিবন্ধটি মন্তব্য:

রিজো এবং ডুং এএসপি.নেট অ্যাপসের বিরুদ্ধে যে আক্রমণটি প্রয়োগ করেছে তার জন্য ওয়েব সাইটটিতে ক্রিপ্টো প্রয়োগের একটি ওરેકল থাকতে হবে যা সাইফারেক্সট প্রেরণ করা হলে কেবল পাঠটি ডিক্রিপ্ট করে না তবে পাঠককে সিফেরেক্সটেড প্যাডিং কিনা তা সম্পর্কে একটি বার্তা দেয় বৈধ

প্যাডিংটি যদি অবৈধ হয় তবে প্রেরক যে ত্রুটি বার্তাটি পান সেটি তাকে সাইটের ডিক্রিপশন প্রক্রিয়াটি কীভাবে কাজ করবে সে সম্পর্কে কিছু তথ্য দেবে।

আক্রমণটি কাজ করার জন্য নিম্নলিখিতটি সত্য হতে হবে:

  • আপনার অ্যাপ্লিকেশনটিতে প্যাডিং অবৈধ হওয়ার বিষয়ে একটি ত্রুটি বার্তা দিতে হবে।
  • কাউকে অবশ্যই আপনার এনক্রিপ্ট করা কুকিজ বা ভিউস্টেটের সাথে छेলা করতে হবে

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

  • ক্রিপড কুকিতে একটি সেশন আইডি সঞ্চয় করুন
  • আসল তথ্যটি সেশনের স্থিতিতে সংরক্ষণ করুন (একটি ডিবিতে অব্যাহত)
  • ত্রুটি ফিরিয়ে দেওয়ার আগে ব্যবহারকারীর তথ্য ভুল হলে একটি এলোমেলো অপেক্ষা করুন, যাতে আপনি এটি সময় করতে পারবেন না

এইভাবে হাইজ্যাক করা কুকি কেবল একটি সেশন পুনরুদ্ধার করতে ব্যবহার করা যেতে পারে যা সম্ভবত উপস্থিত বা অবৈধ নয়।

একোপার্টি সম্মেলনে আসলে কী উপস্থাপন করা হয়েছে তা দেখতে আকর্ষণীয় হবে তবে এখনই আমি এই দুর্বলতা নিয়ে খুব বেশি চিন্তিত নই।


1
@Venemo। আইস্টেড অফ রেসপন্স.কুকিজ.এড (নতুন এইচটিপিপুকি ("ভূমিকা", "প্রশাসন")); আপনি কি করবেন: স্ট্রিং সেশনআইড = গাইড N নিউগুইড ()। টুস্ট্রিং (); অধিবেশন [সেশনআইড] = "ভূমিকা = অ্যাডমিন"; রেসপন্স.কুকিজ.এড করুন (নতুন এইচটিপকিকি ("গুলি", সেশনআইডি)); এবং ক্রিপ্টোটি সনাক্ত করার জন্য প্রতিক্রিয়ার সময় নির্ধারণের জন্য আক্রমণটি সংবেদনশীল। সুতরাং একটি প্রতিক্রিয়া শেষে একটি থ্রেড.স্লিপ (...) যুক্ত করুন এমন সময়গুলি প্রতিরোধ করবে। ত্রুটি হিসাবে আমি ধরে নিয়েছি (এবং প্রায় নিশ্চিত) এটি একটি অ্যাপ্লিকেশন ত্রুটি, তবে এটি নিজেই কিছু পরীক্ষা করা দরকার। সুতরাং কাস্টম ত্রুটি পৃষ্ঠা থাকা প্যাডিং ত্রুটি প্রদর্শন করবে না।
মিকায়েল সোভেনসন

1
@ মিকায়েল, আপনাকে ধন্যবাদ! যাইহোক, কোনও কুকিতে ভূমিকা রাখতে কী বোঝায়? আমি যদি ব্যবহার করি তবে আমি কি সুরক্ষিত Roles.AddUserToRole("Joe", "Admin")কিন্তু আমি কখনই এটি কোনও কুকিতে রাখি না?
ভেনেমো

1
@ ভেনেমো: আমার সম্পাদনা এবং ব্লগ পোস্টের লিঙ্কটি পড়ুন। সাধারণত ফর্ম লগইন সাইটগুলি একটি কুকিতে ভূমিকা রাখে, তবে @ আরিস্টস তার প্রতিক্রিয়ায় উল্লেখ হিসাবে, এটি বন্ধ করা যেতে পারে, এবং এটি বন্ধ করা উচিত।
মিকায়েল সোভেনসন

5
কি পৃথিবীতে ...; 3DES এ ডাউনগ্রেড করবেন না, এটি মোটেও সহায়তা করবে না এবং এটি সত্যই খারাপ পরামর্শ।
দুপুর সিল্ক

2
: আপনি ScottGu এর ব্লগ, যা কিছু অতিরিক্ত তথ্য রয়েছে একটি লিঙ্ক যুক্ত করতে পারেন @Mikael weblogs.asp.net/scottgu/archive/2010/09/18/...
Eilon

40

প্যাডিং ওরাকল আক্রমণগুলি বোঝা

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

  1. ফলাফল 1 : এনক্রিপ্ট হওয়া স্ট্রিংটি সঠিকভাবে ডিক্রিপ্ট হয়েছিল এবং অ্যাপ্লিকেশনটি এটি উপলব্ধি করতে সক্ষম হয়েছিল। অর্থ, যদি এনক্রিপ্ট করা স্ট্রিংটি 10 ​​ডিজিটের অ্যাকাউন্ট নম্বর হয়, ডিক্রিপশন শেষে অ্যাপ্লিকেশনটিতে "1234567890" এর মতো কিছু পাওয়া গেছে এবং "abcd1213ef" নয়

  2. ফলাফল 2 : প্যাডিংটি সঠিক ছিল, তবে ডিক্রিপশনের পরে প্রাপ্ত স্ট্রিংটি গিবারি ছিল যা অ্যাপটি বুঝতে পারে না। উদাহরণস্বরূপ, স্ট্রিংটি "abcd1213ef" এ ডিক্রিপ্ট হয়েছিল তবে অ্যাপটি কেবলমাত্র সংখ্যা প্রত্যাশা করেছিল। বেশিরভাগ অ্যাপ্লিকেশন "অবৈধ অ্যাকাউন্ট নম্বর" এর মতো একটি বার্তা প্রদর্শন করবে।

  3. ফলাফল 3 : প্যাডিংটি ভুল ছিল এবং অ্যাপ্লিকেশনটি একধরণের ত্রুটি বার্তা ফেলেছিল। বেশিরভাগ অ্যাপ্লিকেশন "কিছু ত্রুটি ঘটেছে" এর মতো জেনেরিক বার্তা প্রদর্শন করবে।

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

যদি এই দুটি শর্ত পূরণ হয় তবে আক্রমণকারী শেষ পর্যন্ত বার্তাটি ডিক্রিপ্ট করতে পারে এবং তার ইচ্ছামত যা তা আবার এনক্রিপ্ট করে। এটি সময়ের প্রশ্ন মাত্র।

এটি প্রতিরোধে কী করা যেতে পারে?

  1. সহজ জিনিস - সংবেদনশীল কিছু কখনই ক্লায়েন্টের কাছে প্রেরণ করা উচিত নয়, এনক্রিপ্ট করা বা কোনও এনক্রিপ্ট করা উচিত নয়। এটি সার্ভারে রাখুন।

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

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

পিএসিং প্যাডিং ওরাকল আক্রমণগুলির একটি ভাল ব্যাখ্যা এই ব্লগ পোস্টে পাওয়া যাবে । দাবি অস্বীকার: এটি আমার ব্লগ নয়।


+1 দুর্দান্ত ব্যাখ্যা, ধন্যবাদ! একটি প্রশ্ন: "উপরের তালিকার ফলাফল 2 এবং ফলাফল 3 আক্রমণকারীর কাছে হুবহু একইরকম প্রদর্শিত হচ্ছে তা নিশ্চিত করুন।" -> এএসপি.নেটে কীভাবে আমি এটি অর্জন করতে পারি?
ভেনেমো

3
তাদের একই প্রদর্শিত হওয়ার জন্য, ফলাফল এবং 2 এবং 3 এর জন্য আপনার একই ত্রুটি বার্তা আউটপুট করা উচিত, যার অর্থ আরও সাধারণ ত্রুটি। এইভাবে তাদের পার্থক্য করা যায় না। একটি ভাল ত্রুটি হতে পারে: "একটি ত্রুটি ঘটেছে, দয়া করে আবার চেষ্টা করুন"। অপূর্ণতাটি হ'ল আপনি ব্যবহারকারীকে কম তথ্যমূলক বার্তা দিতে পারেন।
মিকেল সুইভেনস

তাহলে কীভাবে এটি লোকজনকে ওয়েবকনফিগটি ডাউনলোড করতে দেয় ??
ড্যানিয়েল লিটল

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

13

আমি এখনও যা পড়েছি তা থেকে ...

আক্রমণ কাউকে স্নিগ্ধ কুকিগুলি ডিক্রিপ্ট করার অনুমতি দেয়, এতে ব্যাংক ব্যালেন্সের মতো মূল্যবান ডেটা থাকতে পারে

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

যদি কেউ ব্রাউজারের ডেটাতে হাত না পান তবে অনলাইনে থাকা কোনও ব্যবহারকারীর কুকি কীভাবে পাবেন? নাকি আইপি প্যাকেট শুঁকবে?

এটি রোধ করার একটি উপায় হ'ল এসএসএল এনক্রিপশন ছাড়াই কুকিগুলি পরিবহনের অনুমতি না দেওয়া।

<httpCookies httpOnlyCookies="true" requireSSL="true" />

এছাড়াও আরও একটি পদক্ষেপ হ'ল কুকিগুলিতে রোলগুলি সংরক্ষণ করা।

<roleManager enabled="true" cacheRolesInCookie="false">

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

তথ্যসূত্র:
কিছু হ্যাকার কোনও ব্যবহারকারীর কাছ থেকে কুকি চুরি করতে পারে এবং সেই নামের সাথে কোনও ওয়েবসাইটে লগইন করতে পারে?

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

আক্রমণকারীকে ট্র্যাক করার উপায়টি হ'ল প্যাডিংটি অবৈধ check একটি সাধারণ পদ্ধতির সাহায্যে আপনি এগুলি ট্র্যাক করে এগুলি ব্লক করতে পারেন - কীটি খুঁজে পেতে তাদের আপনার পৃষ্ঠায় কয়েক হাজার কল প্রয়োজন!

আপডেট 1।

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

যদি কেউ এই সরঞ্জামটি বা এই পদ্ধতিটি ব্যবহার করার চেষ্টা করে তবে উপরের কোডগুলি সেগুলি ট্র্যাক করতে পারে এবং আপনি এই জাতীয় "পরিষেবা থেকে বিরত রাখুন (ডস)" এর মতো সরল কোড সহ আপনার পৃষ্ঠা থেকে তাদের অবরুদ্ধ করতে পারেন বা অস্বীকার প্রতিরোধের জন্য এই কোডটি পছন্দ করতে পারেন পরিষেবা

আপডেট 2

আমি এখন পর্যন্ত যা পড়েছি তা থেকে এটি মনে হয় যে কেবল ত্রুটি সম্পর্কে তথ্য না দেওয়ার জন্য কেবল এটিই দরকার এবং কেবল একটি কাস্টম ত্রুটি পৃষ্ঠা স্থাপন করুন এবং যদি আপনি পছন্দ করেন তবে আপনি কেবল এই পৃষ্ঠাতে তৈরি করতে এবং এলোমেলো দেরি করতে পারেন।

এই ইস্যুতে একটি খুব আকর্ষণীয় ভিডিও

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

ভিউস্টেট আক্রমণ আবিষ্কারের জন্য এটির আরও একটি মাত্রা অনুসরণ করে।


অ্যারিস্টোস, সুতরাং, সর্বোপরি, এটি দেখতে অন্য কোনও জেনেরিক কুকি-চুরি-ভিত্তিক পদ্ধতির মতো দেখাচ্ছে, তাই না? তাহলে কেন তারা বলছেন যে এটি খুব গুরুতর?
ভেনেমো

@ ভেনেমো কারণ তারা যদি সত্যিই সেই চাবিটি পেতে পারে তবে যে কোনও পৃষ্ঠায় ডেটা পোস্টে কিছুটা আরও ক্ষতি করতে পারে কারণ তারা সেই সুরক্ষাটি ভেঙে দেয় ... এটি গুরুতর তবে পরবর্তী পদক্ষেপে এবং বাস্তবটিতে যাওয়া অসম্ভবও কঠিন সিস্টেমে বিরতি। উদাহরণস্বরূপ এই সাইটটি mypetfriend.gr স্কয়ার ইনজেকশন মঞ্জুরি দেয়। তবে আপনি কি এটি ভেঙে দিতে পারেন? সুরক্ষাও কি এত কম?
এরিস্টোস

@ ভেনেমো আমি মনে করি যে আপনি এই আক্রমণটির জন্য বিশেষভাবে চূড়ান্ত মোড়কে চলাচল করছিলেন তা হ'ল আইপিএসের যে পণ্যটিকে অবৈধ প্যাডিংয়ের তুলনায় স্বাভাবিকের চেয়ে বেশি লক করা! (এবং এটিই আমি পরের দিনগুলিতে স্থির করতে যাচ্ছি) :)
এরিস্টোস

1
@ অ্যারিস্টস - আপনি যে লিঙ্কটি যুক্ত করেছেন অন্য প্রশ্নের উত্তর আমি পড়েছি। এটি যদিও ভিউস্টেটের সাথে সম্পর্কিত। যেহেতু আমি এএসপি.এনইটি এমভিসি ব্যবহার করি, তাই আমি ভিউস্টেট ব্যবহার করি না। এবং আমি এটি বুঝতে পারি না, কীভাবে এই বিবরণটি এই সুরক্ষা ইস্যুতে অনুবাদ করে?
ভেনেমো

এমভিসির জন্য ভেনেমো @ আমি জানি না বলে আমি বলতে পারি না। ভিউস্টেটটি সেই অংশ যা চাবিটি খুঁজতে আক্রমণ করে। এমভিসি কীভাবে পৃষ্ঠার অখণ্ডতা ট্র্যাক করে তা আমি জানি না।
এরিস্টোস

12

এখানে এমএসের প্রতিক্রিয়া। এগুলি "একটি কাস্টম ত্রুটি পৃষ্ঠা ব্যবহার করুন" এ ফোটে এবং আপনি কোনও ক্লু দিবেন না।

সম্পাদনা
করুন স্কটগ থেকে আরও কিছু বিশদ তথ্য is


ধন্যবাদ, এটি আমি সমস্ত বরাবর জিজ্ঞাসা করা হয়েছে। সুতরাং মূলত একটি সাধারণ কাস্টম ত্রুটি পৃষ্ঠা আমাকে এই দুর্বলতার সমস্ত প্রভাব থেকে বাঁচাতে পারে?
ভেনেমো

2
@ ভেনেমো: হ্যাঁ, এবং 3 ডিইএসের সুপারিশকারী লোকদের নিঃশব্দ করা উচিত; এটি অবিশ্বাস্যভাবে দায়িত্বজ্ঞানহীন এবং এমনকি মূল সমস্যাটির সমাধানও করে না! এটি বেশ মর্মাহত। দয়া করে, আমি আশা করি কেউই তাদের পরামর্শ অনুসরণ না করে এবং মাইক্রোসফ্ট আধিকারিকের পরামর্শ অনুযায়ী তা করে।
দুপুর সিল্ক

1
@ নুন - আচ্ছা, এই প্রকারের কাস্টম ত্রুটি পৃষ্ঠাটি যে কোনও উত্পাদন সাইটের জন্য থাকা আবশ্যক, যাতে দেখা যাচ্ছে যে এই জারি করা এতটা গুরুতর নয়। :)
ভেনেমো

12

Http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx- এ আলোচনা থেকে নেওয়া স্কটগুর প্রতিক্রিয়া যুক্ত করা হচ্ছে

কাস্টমআরার্সের পরিবর্তে কাস্টম আইএইচটিপমোডুল প্রভাবিত হয়?

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

উত্তর: আমি সর্বদা অনুসন্ধান পৃষ্ঠায় পুনর্নির্দেশের জন্য মডিউলটি অস্থায়ীভাবে আপডেট করার পরামর্শ দেব। এই আক্রমণটি যেভাবে কাজ করে তার মধ্যে একটি হ'ল 404 এবং 500 ত্রুটির মধ্যে পার্থক্য দেখায়। সর্বদা একই HTTP কোডটি ফিরিয়ে দেওয়া এবং তাদের একই জায়গায় প্রেরণ করা এটিকে অবরুদ্ধ করতে সহায়তা করার এক উপায়।

নোট করুন যে যখন প্যাচটি এটি ঠিক করার জন্য বেরিয়ে আসে তখন আপনাকে এটি করার প্রয়োজন হবে না (এবং পুরানো আচরণে ফিরে যেতে পারেন)। তবে এই মুহুর্তে আমি ক্লায়েন্টদের কাছে 404 এবং 500 এর মধ্যে পার্থক্য না করার পরামর্শ দিচ্ছি।

আমি 404 এবং 500 ত্রুটির জন্য বিভিন্ন ত্রুটি ব্যবহার চালিয়ে যেতে পারি?

প্রশ্ন: আমি এটি গ্রহণ করেছি যে আমরা উপরে বর্ণিত নীতিগুলি লঙ্ঘন না করে ত্রুটি-বিহীন পুনঃনির্দেশ ছাড়াও একটি কাস্টম 404 পৃষ্ঠা সংজ্ঞায়িত করতে পারি?

উত্তর: না - যতক্ষণ না আমরা আসল ফিক্সের জন্য কোনও প্যাচ প্রকাশ করি না, ততক্ষণ আমরা উপরোক্ত কাজের প্রস্তাবটি প্রস্তাব করি যা সমস্ত ত্রুটিকে একত্রিত করে। এই আক্রমণটি যেভাবে কাজ করে তার মধ্যে একটি হ'ল 404 এবং 500 ত্রুটির মধ্যে পার্থক্য দেখায়। সর্বদা একই HTTP কোডটি ফিরিয়ে দেওয়া এবং তাদের একই জায়গায় প্রেরণ করা এটিকে অবরুদ্ধ করতে সহায়তা করার এক উপায়।

নোট করুন যে যখন প্যাচটি এটি ঠিক করার জন্য বেরিয়ে আসে তখন আপনাকে এটি করার প্রয়োজন হবে না (এবং পুরানো আচরণে ফিরে যেতে পারেন)। তবে এই মুহুর্তে আপনার ক্লায়েন্টদের কাছে 404 এবং 500 এর মধ্যে পার্থক্য করা উচিত নয়।

এটি কীভাবে ওয়েবকনফিগের প্রকাশের অনুমতি দেয়?

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

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

সম্পাদনা করুন: দ্বিতীয় ব্লগপোস্টে http://weblogs.asp.net/scottgu/archive/2010/09/20/f یرतः-asked-questions-bout-the-asp-net-security-vulnerability.aspx- এ দ্বিতীয় ব্লগপোস্টে অতিরিক্ত FAQ উপলব্ধ


দ্বিতীয় প্রশ্নের উত্তর দুটি তারকাচিহ্ন দিয়ে শেষ হয়। মনে হয় কিছু পাদটীকা বা কোয়ালিফায়ার পাঠ্য কোথাও যুক্ত হয়েছে?
স্কট মিচেল

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


3

কয়েকটি উল্লেখযোগ্য লিঙ্ক:

[এর গুরুত্বের দিকটির উত্তর দিতে (যা প্রকাশিত হয়েছে এবং অন্যান্য উত্তরগুলি কীভাবে প্রকাশিত হয়েছে)।]

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

আরও গুরুতরভাবে যদি আপনি সেশনগুলি কর্মজীবন প্রক্রিয়াকালীন সময়ের জন্য প্রসারণ করতে সক্ষম হন বা ওয়েব ফার্মগুলিকে (যেমন ফার্মের সমস্ত দৃষ্টান্ত যে কোনও ব্যবহারকারীর সেশন পরিচালনা করতে পারে) মঞ্জুরি দিতে চান তবে কীটি কঠোর কোডিং করা দরকার, এটি করা হয় web.config:

[...]
  <system.web>
    <machineKey
        decryption="AES"
        validation="SHA1"
        decryptionKey="57726C59BA73E8A4E95E47F4BC9FB2DD"
        validationKey="158B6D89EE90A814874F1B3129ED00FB8FD34DD3"
      />

এগুলি অবশ্যই নতুন তৈরি করা কীগুলি, আমি উইন্ডোজ ক্রিপ্টোগ্রাফিক র্যান্ডম নম্বর জেনারেটরটি অ্যাক্সেস করতে নিম্নলিখিত পাওয়ারশেলটি ব্যবহার করি:

$rng = New-Object "System.Security.Cryptography.RNGCryptoServiceProvider"
$bytes = [Array]::CreateInstance([byte], 20)
$rng.GetBytes($bytes)
$bytes | ForEach-Object -begin { $s = "" } -process { $s = $s + ("{0:X2}" -f $_) } -end { $s}

(বৈধতার জন্য 20 এবং ডিক্রিপশন কীগুলির জন্য 16 টি অ্যারের দৈর্ঘ্য ব্যবহার করে Using)

নির্দিষ্ট ত্রুটি ফাঁস না করার জন্য সর্বজনীন ত্রুটি পৃষ্ঠাগুলি সংশোধন করার পাশাপাশি উপরের কীগুলি (বা চক্র কর্মী প্রক্রিয়াগুলি যদি তারা কিছুক্ষণ চলমান থাকে) পরিবর্তন করার জন্য এটি ভাল সময় বলে মনে হয়।

[2010-09-21 সম্পাদনা করুন: শীর্ষে লিঙ্ক যুক্ত]


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

2

বিষয়টি নিয়ে অতিরিক্ত গবেষণার পরে আমি আমার ব্লগটিতে আমার সম্পূর্ণ গ্রহণ পোস্ট করেছি । আমি মনে করি এটির গুরুত্বপূর্ণ সাফাই কেন তারা একটি লেখক কুকি তৈরি করে চলেছে।


কেবল কিছু তথ্য সোজা পেতে চাই:

  1. আক্রমণ আপনাকে সরাসরি মেশিন কীটি পেতে দেয় না। এটি বলেছিল যে এটির মতো এটির মতোই এটি বার্তাগুলি ডিক্রিপ্ট করতে এবং নতুনকে পুনরায় / এনক্রিপ্ট করতেও সহায়তা করে।
  2. আসল কীগুলি পাওয়ার উপায়টি তাদের 1 টির মতো পুনরায় / এনক্রিপ্ট করার ক্ষমতা এবং ওয়েবকনফিগটি ব্যবহার করে ability দুর্ভাগ্যক্রমে এমন কিছু কারণ রয়েছে যেগুলি কিছু কেন ওয়েব স্তনফাইজে সাইটগুলি স্তরে রেখেছিল (বিভিন্ন আলোচনা), এবং নমুনা ভিডিওতে তারা ডটনেটুকের ডিফল্ট হওয়া থেকে উপকৃত হয়।
  3. সেখানে ওয়েবকনফিগটি পেতে সমস্ত কিছু জানাতে যে তারা ওয়েবরেসোর্স.এক্সডি এবং / অথবা স্ক্রিপ্টসোর্স.এক্সডি ব্যবহার করছে। আমি ভেবেছিলাম এগুলি কেবল এম্বেড থাকা সংস্থাগুলির সাথেই কাজ করেছে তবে মনে হয় এটি কেবল তেমনটি নয়।
  4. অ্যাপ্লিকেশনটি যদি এসপ নেটওয়্যার এমভিসি হয় তবে আমাদের সত্যই ওয়েবরেসোর্স.এক্সডি এবং / অথবা স্ক্রিপ্টসোর্স.এক্সডি লাগবে না, যাতে সেগুলি বন্ধ করা যায়। আমরা ভিউস্টেটও ব্যবহার করি না। এটি বলেছিল, অন্যান্য এসপ নেট’র বৈশিষ্ট্যগুলি যদি যথাযথভাবে স্থিতিশীলতার সাথে আলাদা আলাদা তথ্য দেয় তবে তা আমার কাছে অস্পষ্ট ie অর্থাত জানি না যে প্যাডিং অগ্রাহ্য প্রমাণীকরণের টিকিটে বৈধ ফলাফলগুলি প্যাড করার সময় ভুল ক্ষেত্রে অকার্যকর ফলাফল দেয় কিনা (জানি না যদি তা না হয় তবে) ... একই বিশ্লেষণটি সেশন কুকিতে প্রয়োগ করা উচিত।
  5. অ্যাসপ.net সদস্যপদ প্রদানকারী কুকিগুলির ভূমিকা 'ক্যাশে' করে, এটি বন্ধ করে দিন।

প্রায় 1 হিসাবে, এনক্রিপ্ট হওয়া বার্তাগুলি 100% সালমানের প্রয়োজন হতে পারে না ম্যাসেজের কোথাও একটি ছোট্ট আবর্জনা সহ্য করার প্রয়োজন, কারণ বার্তায় 1 টি ব্লক রয়েছে যা মানটি ডিক্রিপ্ট করে যে নিয়ন্ত্রণ করা যায় না।

পরিশেষে আমি বলতে চাই যে এই সমস্যাটি এমএস এর ক্ষেত্রে এই ক্ষেত্রে তার নিজস্ব নির্দেশিকা অনুসরণ না করার ফলস্বরূপ: একটি বৈশিষ্ট্য ক্লায়েন্টকে প্রম্পট প্রমাণ হিসাবে পাঠানো কোনও কিছুর উপর নির্ভর করে।


আরো:

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

লেখক কুকি স্বাক্ষরিত এবং কাগজের তথ্য থেকে তারা যদি সত্যিকারের কীগুলিতে না পান তবে তারা স্বাক্ষরিত কুকি তৈরি করতে সক্ষম হবে না (যেমন তারা লেখার আগে কুকি ফোর করার আগে ভিডিওতে করেছিল)।

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



আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.