সুরক্ষা সম্পর্কে প্রতিটি প্রোগ্রামারকে কী জেনে রাখা উচিত? [বন্ধ]

427

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

আমি খুব নিশ্চিত যে কেউই সুরক্ষা সম্পর্কে প্রতিটি জিনিস শিখতে পারে না তবে নিশ্চিত যে কোনও প্রোগ্রামার বা আইটি শিক্ষার্থীর এটি সম্পর্কে একটি "ন্যূনতম" জ্ঞান থাকা উচিত এবং আমার প্রশ্নটি এই ন্যূনতম জ্ঞানটি কী?

আপনি কি কিছু ই-বুকস বা কোর্সগুলির পরামর্শ দিতে পারেন বা কিছু এই রাস্তাটি শুরু করতে সহায়তা করতে পারেন?

security 
— এমএইচ
সূত্র
6
— থমাস
118
বিধি # 1: কখনও ব্যবহারকারীর ইনপুট বিশ্বাস করবেন না। এমনকি এটি আপনার দাদী হলেও নয়
— অ্যান্টনি ফোরলনি
2
.. এবং এই থ্রেডটিতে দুর্দান্ত তথ্যও রয়েছে - stackoverflow.com/questions/72394/…
— শ্রীপতি কৃষ্ণন
আমার প্রশ্নটি কেবল প্রোগ্রামার এবং তাদের ভুল সম্পর্কে নয়, আইটি এবং কম্পিউটার বিজ্ঞানের শিক্ষার্থীদের সম্পর্কেও
— মোহাম্মদ আলহামউদ
1
আপনার ত্রুটি বার্তা দেখুন। আপনি ব্যবহারকারীবান্ধব হতে চাইলে, "এই অ্যাকাউন্টটি বিদ্যমান নেই" এবং "পাসওয়ার্ডটি অবৈধ" এর মধ্যে পার্থক্য কিছু ক্ষেত্রে বিপজ্জনক হতে পারে।
— মাইকেল মায়ার

উত্তর:

551

আপনি যদি আপনার অ্যাপ্লিকেশনগুলি সুরক্ষিত রাখতে চান তবে নীতির কথা মাথায় রাখুন:

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

আপনার অ্যাপ্লিকেশনগুলি সুরক্ষিত করার জন্য অনলাইনে কয়েকটি দুর্দান্ত বই এবং নিবন্ধ রয়েছে:

অ্যাপ্লিকেশন সুরক্ষার সেরা অনুশীলনে আপনার বিকাশকারীদের প্রশিক্ষণ দিন

কোডব্যাশিং (প্রদত্ত)

সুরক্ষা উদ্ভাবন (অর্থ প্রদান)

সুরক্ষা কম্পাস (প্রদত্ত)

OWASP ওয়েবগোট (বিনামূল্যে)

— বিগনাম
সূত্র
+1 "শোষণকারী সফ্টওয়্যার: কীভাবে কোড ভাঙবেন" একটি দুর্দান্ত বই, তবে যে স্লাইডটি আপনাকে সংযুক্ত করেছে তা ভয়ঙ্কর।
— রোক
7
তবে দুর্ভাগ্যক্রমে কোনও আধুনিক সিস্টেমে ন্যূনতম সুযোগ-সুবিধার নীতিটি ইনস্ট্যান্ট করা প্রায় অসম্ভব। উদাহরণস্বরূপ, লিনাক্স কার্নেল (উত্স বর্তমানে আমি ব্যবহার করছি) সি কোডের 9.4 মিলিয়ন লাইন এবং অ্যাসেমব্লির 400K এর বেশি লাইন ধারণ করে, এগুলি সবই একটি বাধা ছাড়াই প্রসঙ্গে চলে। এই লক্ষ লক্ষ লাইনের একটিতে একটি সাধারণ ভুল গণনা (সম্ভবত উদ্দেশ্যমূলক) পুরো সিস্টেমকে আপস করবে। সম্ভবত পরবর্তী শতাব্দীতে বা দু'একটিতে একটি সমাধান উদ্ভূত হবে, সম্ভবত না যেমন নিরাপদ ওএস / ভাষা / ফ্রেমওয়ার্ক তৈরি করার বিষয়ে কেউই যত্নবান না।
— L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳
1
আমি সেই তালিকায় "দ্য ওয়েব অ্যাপ্লিকেশন হ্যাকারের হ্যান্ডবুক" যুক্ত করব।
— ছাড়িয়ে গেছে
34
"কখনও ব্যবহারকারীর ইনপুট বিশ্বাস করবেন না!" প্রতিস্থাপন করুন! "কোনও ইনপুট বিশ্বাস করবেন না!"। অন্যান্য সফ্টওয়্যার থেকে আসা ইনপুটগুলি ব্যবহারকারীর ইনপুট হিসাবে একই আচরণ করা উচিত - উদাহরণস্বরূপ, ওয়েবসাইট লগিংয়ে বেশিরভাগ লোক ব্যবহারকারী-এজেন্ট / ব্রাউজার আইডি ক্ষেত্রটিকে 'ব্যবহারকারী ইনপুট' হিসাবে ভাবেন না তবে এটি কেবল সহজেই বলতে পারে, বলুন, এসকিউএল ইনজেকশন.
— পিটারিস
2
@ L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ ওয়েল, মাইক্রোসফ্ট রিসার্চ পরীক্ষামূলক ওএস (সিঙ্গুলারিটি)। নেট উপর নির্মিত, যা প্রাথমিক লক্ষ্য হিসাবে সুরক্ষাকে লক্ষ্য করে (কোনও বাফার উপচে পড়েনি, হ্যাঁ!)! কোনও প্রক্রিয়া মেমরি ভাগ করে নেওয়া, কোনও কোড স্ব-পরিবর্তনকরণ, এমনকি ডিভাইস চালকরা .NET এ অন্য একটি সফ্টওয়্যার বিচ্ছিন্ন প্রক্রিয়া। বেশ আকর্ষণীয় ধারণা, তবে এটি মানুষের কাছে ঠেলাঠেলি করা খুব শক্ত হবে (সবচেয়ে বড় কথা, এটি বিদ্যমান সফ্টওয়্যার বা এমনকি ড্রাইভারের সাথে সামনের দিকে সামঞ্জস্যতা করতে পারে না; লিনাক্সের প্রথম দশ বছরের মতো: ডি)।
— লুয়ান
102

প্রোগ্রামারদের জন্য সুরক্ষার # 1 বিধি: আপনার নিজের রোল করবেন না

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

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

— টাইলার ম্যাকহেনরি
সূত্র
10
এটি আমার মতে একটি খারাপ নিয়ম। আপনার সম্পত্তিতে কোনও প্রকৃত আগ্রহের চেয়ে আপনি কেবল প্ল্যাটফর্মটি বেছে নেওয়ার কারণে আপনাকে মূলত টার্গেট করা যেতে পারে। তৃতীয় পক্ষের প্ল্যাটফর্মগুলিতে যে সমস্ত সুরক্ষা গর্ত পাওয়া যায় সেগুলি এবং তা ব্যবহার করার কারণে তাত্ক্ষণিকভাবে ঝুঁকির মধ্যে থাকা সমস্ত পণ্য সম্পর্কে চিন্তা করুন। আমি তৃতীয় পক্ষের কাছে আমার সুরক্ষা বিশ্বাস করতে এত তাড়াতাড়ি করব না।
— ফস্কো
9
আমি মনে করি এটি ক্রিপ্টোর জন্য একটি ভাল নিয়ম - আপনার নিজের এনক্রিপশন ঘূর্ণন বিপর্যয়ের একটি রেসিপি। তবে আপনার নিজের ব্লগ ইঞ্জিনটি ঘূর্ণন করা আরও সুরক্ষিত হতে পারে যেহেতু ফসকো দেখিয়েছে - আপনি যদি নিজের রোল করেন তবে ওয়ার্ডপ্রেস ইনস্টলগুলির দ্বারা মোকাবিলা করতে হবে এমন স্বয়ংক্রিয় আক্রমণ দ্বারা আপনি ধরা পড়ার সম্ভাবনা কম।
— জেমস পি ম্যাকগ্রা
5
এটি ক্রিপ্টোর ক্ষেত্রে আসে, এই নিয়মটি একেবারে সঠিক। নিজের ক্রিপ্টো, পিরিয়ড লিখবেন না। এটি যখন তৃতীয় পক্ষের প্ল্যাটফর্মগুলি ব্যবহার করার কথা আসে তখন এটি নির্ভর করে। কিছু প্ল্যাটফর্ম অন্তর্নিহিত আরও সুরক্ষিত, কিছু প্ল্যাটফর্ম অন্তর্নিহিতভাবে কম সুরক্ষিত এবং বেশিরভাগ প্ল্যাটফর্মগুলি সম্ভবত কিছু সুরক্ষা বৈশিষ্ট্য সরবরাহ করে তবে কিছু পরিচিত আক্রমণকারী ভেক্টরও সরবরাহ করে। গিথুবে একটি সুরক্ষা গর্তের কারণ হিসাবে সাম্প্রতিকতম কারাগারের দুর্বলতা নিন । নিঃসন্দেহে রেইলগুলি অনেকগুলি সুরক্ষা বৈশিষ্ট্য সরবরাহ করে তবে এতে নিরাপত্তাহীন ডিফল্টগুলির সাথে কিছু শক্তিশালী বৈশিষ্ট্যও রয়েছে।
— মাইকেল কোপিনস্কি
7
যখন ক্রিপ্টোর কথা আসে, নিজের রোল করবেন না - তবে আপনি যে জিনিসটি ব্যবহার করছেন তা বুঝতে পারেন। আপনি যদি বুঝতে না পারছেন যে দুটি বার্তার জন্য আরসি 4 এর জন্য একই এনক্রিপশন কীটি কেন একটি ভয়ঙ্কর ধারণা, উদাহরণস্বরূপ, কোনও স্ট্রিম সাইফার ব্যবহার করার আগে পড়ুন।
— ক্রিস্টোফার ক্রিউটজিগ
3
এমনকি হার্টব্লেড বাগের পরেও এটি সুস্পষ্ট নিয়ম apparent কাস্টম বা মালিকানাধীন প্রকল্পে হিটবেবলযুক্ত বাগটি খুঁজে পেতে তার পক্ষে কতটা কষ্ট হত তা কল্পনা করুন। যদি আপনি নিজের রোল করেন তবে আপনি কেবল অস্পষ্টতার আড়ালে লুকিয়ে রয়েছেন এবং কী কী বাগগুলি শোষণ করা হতে পারে তা জানেন না।
— স্কেয়কি
71

প্রতিটি প্রোগ্রামারকে কোড শোষণ করার পদ্ধতি কীভাবে লিখতে হবে তা জানা উচিত।

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

— রুক
সূত্র
10
আমি তর্ক করবো এটি মোটেও প্রয়োজনীয় নয়। কেবলমাত্র নীতিটি মেনে চলুন: আক্রমণকারী যদি কোনও ধরণের স্মৃতি দুর্নীতির কারণ হতে পারে তবে নিজেকে মালিকানাধীন বলে বিবেচনা করুন। প্রকৃতপক্ষে লেখার (কাজ করা) শোষণের বিবরণে প্রবেশ করার দরকার নেই।
— newgre
6
@ নতুন প্রত্যেকটি দুর্বলতা বাফার ওভারফ্লো নয়। প্রচলিত দুর্বলতা গণ্যকরণ সিস্টেম দ্বারা আচ্ছাদিত কয়েক হাজার দুর্বলতা রয়েছে। একজন প্রোগ্রামারকে আক্রমণকারীর মন বোঝা দরকার বা সে অজান্তেই ভুল করতে পারে।
— রোক
1
আমি জানি যে তাদের প্রত্যেকটিই বাফার ওভারফ্লো নয়, তবে সাধারণত যে কোনও কিছু "শোষণ" হিসাবে চিহ্নিত করা হয় তা কোনও না কোনও মেমরির দুর্নীতির উপর ভিত্তি করে: বাফার ওভারফ্লো, ডাবল-ফ্রি, হিপ ওভারফ্লো, ইন্টিজার সম্পর্কিত ওভারফ্লো, ফর্ম্যাট স্ট্রিং , ইত্যাদি অবশ্যই লজিক বাগের মতো অন্যান্য জিনিস রয়েছে তবে এটি শুরু হওয়া এই উত্তরটির বিষয় ছিল না।
— newgre
5
@ নিউগ্রে এটি এক ধরণের শোষণ, তবে আজ স্মৃতি দুর্নীতির সমস্যার চেয়ে ওয়েব অ্যাপ্লিকেশন ত্রুটিগুলি লাভ করার জন্য আরও বেশি শোষণ লেখা রয়েছে। এক্সপ্লোরিটগুলি এসকিউএল ইনজেকশন উপকারে লিখিত হয়, স্থানীয় ফাইল অন্তর্ভুক্ত, সিএসআরএফ, এবং এক্সএসএস, এগুলি সাধারণ সমস্যা। (উত্স: exploit-db.com )
— ২ok
1
আমি এটির সাথে একমত, যদি আপনি নিজেই শোষণগুলি লিখতে পারেন তবে আপনি বুঝতে পারবেন যে হ্যাকারদের মনে কী সর্বোচ্চ যেতে পারে!
— লিনাক্সেসি
42

সুরক্ষা একটি প্রক্রিয়া, কোনও পণ্য নয়।

অনেকেই এই স্পষ্ট বিষয়টিকে ভুলে যেতে বলে মনে করছেন।

— ericteubert
সূত্র
23

আমি সিডাব্লুইই / সানস শীর্ষ 25 সবচেয়ে বিপজ্জনক প্রোগ্রামিং ত্রুটিগুলি পর্যালোচনা করার পরামর্শ দিচ্ছি । ভবিষ্যতে নিয়মিত আপডেটের প্রতিশ্রুতি সহ এটি 2010 এর জন্য আপডেট করা হয়েছিল। 2009 সংস্করণ পাশাপাশি পাওয়া যায়।

Http://cwe.mitre.org/top25/index.html থেকে

২০১০ সিডব্লিউই / সানস শীর্ষ 25 সর্বাধিক বিপজ্জনক প্রোগ্রামিং ত্রুটিগুলি হল সর্বাধিক বিস্তৃত এবং সমালোচনামূলক প্রোগ্রামিং ত্রুটির একটি তালিকা যা গুরুতর সফ্টওয়্যার দুর্বলতার দিকে নিয়ে যেতে পারে। এগুলি প্রায়শই সন্ধান করা সহজ এবং শোষণে সহজ। এগুলি বিপজ্জনক কারণ তারা ঘন ঘন আক্রমণকারীদের সফ্টওয়্যারটি সম্পূর্ণরূপে গ্রহণ, ডেটা চুরি করতে বা সফ্টওয়্যারটিকে কিছুতেই কাজ করতে বাধা দেবে।

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

— jschmier
সূত্র
1
নোট করুন যে তালিকার শীর্ষে 4 টি ত্রুটি (এবং অন্যদের মধ্যে একটি গোছা) সমস্ত একই ত্রুটি - ইনপুটকে বিশ্বাস করে।
— ক্রিস ডড
13

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

— রেভস টভানফসন
সূত্র
এমআইটি কোর্সের লিঙ্কটি কাজ করে না
— আন্তোনিওসিএস
1
লিঙ্কগুলি স্থির (এখনের জন্য)। ধন্যবাদ।
— tvanfosson
10

মজিলায় ওয়েব সুরক্ষা টিম একটি দুর্দান্ত গাইডকে একত্রিত করেছে , যা আমরা আমাদের সাইট এবং পরিষেবাগুলির উন্নয়নে মেনে চলি।

— Potch
সূত্র
8

ফ্রেমওয়ার্ক এবং এপিআইগুলিতে সুরক্ষিত ডিফল্টগুলির গুরুত্ব:

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

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

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

আমি নিম্নলিখিত যোগ করা হবে:

  • ডিজিটাল স্বাক্ষর এবং ডিজিটাল শংসাপত্রগুলি কীভাবে কাজ করে
  • স্যান্ডবক্সিং কি

বিভিন্ন আক্রমণকারী ভেক্টরগুলি কীভাবে কাজ করে তা বুঝুন:

  • নেটিভ কোডে বাফার ওভারফ্লোস / আন্ডারফ্লোস ইত্যাদি
  • সামাজিক প্রকৌশলী
  • ডিএনএসের স্পোফিং
  • মাঝখানের ব্যাক্তি
  • সিএসআরএফ / এক্সএসএস এবং অন্যান্য
  • এসকিউএল ইনজেকশন
  • ক্রিপ্টো আক্রমণ (উদাঃ দুর্বল ক্রিপ্টো অ্যালগরিদম যেমন DES ব্যবহার করে)
  • প্রোগ্রাম / ফ্রেমওয়ার্ক ত্রুটি (উদা: গিথুবের সর্বশেষ সুরক্ষা ত্রুটি)

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

— মিগুয়েল পিং
সূত্র
4

আপনি যখন কোনও এন্টারপ্রাইজ বা আপনার নিজের সফ্টওয়্যার তৈরি করছেন তখন আপনার কেবল হ্যাকারের মতোই চিন্তা করা উচিত we আমরা জানি হ্যাকাররাও সমস্ত বিষয়ে বিশেষজ্ঞ নয় তবে যখন তারা কোনও দুর্বলতা খুঁজে পায় তারা সমস্ত তথ্য সংগ্রহ করে এটিতে খোঁড়াখুঁড়ি শুরু করে it জিনিসগুলি এবং অবশেষে আমাদের সফ্টওয়্যারটিতে আক্রমণ করে so সুতরাং এই জাতীয় আক্রমণগুলি রোধ করার জন্য আমাদের কিছু সুপরিচিত নিয়ম অনুসরণ করা উচিত:

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

আপনি নিম্নলিখিত লিঙ্কগুলিতে আরও সুরক্ষা সংস্থান খুঁজে পেতে পারেন:

আপনার অ্যাপ্লিকেশন বিক্রেতার সুরক্ষা প্রবাহ সম্পর্কে আরও তথ্যের জন্য গুগল।

— রাহুল_প্রতাপ
সূত্র
3
  1. কেন গুরুত্বপূর্ণ।
  2. এটি ট্রেড-অফ সম্পর্কে সমস্ত।
  3. ক্রিপ্টোগ্রাফিটি মূলত সুরক্ষা থেকে দূরে।
— রিচার্ড
সূত্র
3

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

আমি সামাজিক প্রকৌশল (এবং কেভিন মিটনিক ) এর সাথেও পরিচিত হতে পারি ।

বাস্তব বিশ্বে সুরক্ষা কীভাবে কার্যকর হয় সে সম্পর্কে একটি ভাল (এবং মনোরঞ্জনজনক) বইয়ের জন্য, আমি ক্লিফ স্টলের চমৎকার (যদিও কিছুটা তারিখের) 'দ্য কোকিলের ডিম' সুপারিশ করব ।

— ড্যান এস্পারজা
সূত্র
3

এছাড়াও সমস্ত প্রধান আক্রমণকারী ভেক্টর / দুর্বলতার শ্রেণিবদ্ধকরণের জন্য ওডাব্লুএএসএসপি শীর্ষ 10 তালিকা পরীক্ষা করে দেখুন be

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

— মাইকেল কোপিনস্কি
সূত্র
2

আপনার ব্যবহারকারীর পাসওয়ার্ডগুলি লবণ এবং হ্যাশ করুন। আপনার ডেটাবেজে প্লেটেক্সটে এগুলি কখনও সংরক্ষণ করবেন না।

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