প্রতিটি সি প্রোগ্রামারকে অবশ্যই সচেতন হওয়া উচিত সুরক্ষা ঝুঁকি / দুর্বলতাগুলি? [বন্ধ]


13

উচ্চ স্তরের প্রোগ্রামিং ল্যাঙ্গুয়েজগুলি থেকে ভাল-পরীক্ষিত এবং প্রমাণিত এপিআই ব্যবহার করার বিপরীতে হার্ডওয়্যারটিতে ঘনিষ্ঠ যোগাযোগ থাকার কারণে অনেকগুলি নিরাপত্তা ঝুঁকি রয়েছে। জাভা-র মতো ভাষার চেয়ে সিতে বাফার উপচে পড়া খুব সহজ much

প্রতিটি সি প্রোগ্রামার (সি প্রোগ্রামারগুলির সাথে সম্পর্কিত IE দুর্বলতা) সম্পর্কে সচেতন হওয়া উচিত এমন কী কী ঝুঁকি বা দুর্বলতা (যেমন বাফার ওভারফ্লো)? এগুলি কী সমস্যার সৃষ্টি করতে পারে? এগুলি কীভাবে এড়ানো যায় এবং প্রোগ্রামগুলিতে এগুলি ঘটানোর জন্য সাধারণ ভুলগুলি কী কী?


এই তালিকাটি সম্পর্কে কী: owasp.org/index.php/Category:OWASP_Top_Ten_Project এর চেয়ে আর কী দরকার?
এস। লট

2
@ এস.লোট: ওয়েব বিকাশে সুরক্ষার সমস্যাগুলি সম্পর্কে এটি খুব বেশি বলে মনে হচ্ছে। আমি আসলে যা চেয়েছি তার চেয়ে সাধারণভাবে আরও বেশি সংস্থান রয়েছে বলে মনে হয়, মনে হয়।
Anto

@ এন্টো: দয়া করে সুরক্ষা এবং আপনি যে সুরক্ষা সম্পর্কে জিজ্ঞাসা করছেন তার সমস্ত সম্পদের মধ্যে পার্থক্য করার জন্য প্রশ্নটি আপডেট করুন।
এসলট

@ এস.লোট: আপনার অর্থ কী তা আমি নিশ্চিত নই। আমি বেশিরভাগ সি প্রোগ্রামারদের কাছে সুরক্ষার জন্য জিজ্ঞাসা করি, এটি হল, বাফার ওভারফ্লোগুলি এবং সিতে সম্ভব অন্যান্য জিনিসগুলির মতো জিনিস
এন্টো

@ এন্টো: "আমি আসলে যা জিজ্ঞাসা করছি তার চেয়ে সাধারণভাবে [ওয়েব সুরক্ষা?] এ আরও বেশি সংস্থান রয়েছে বলে মনে হচ্ছে" মনে হয় আপনি এমন কোনও সুরক্ষা সম্পর্কে জিজ্ঞাসা করছেন যা ওয়েব সুরক্ষা নয়। সত্য? যদি তা হয় তবে দয়া করে আপনি যা খুঁজছেন তা ব্যাখ্যা করতে প্রশ্নটি আপডেট করুন। মিথ্যা? তারপর আপনি হয় , ওয়েব নিরাপত্তা সম্পর্কে জিজ্ঞাসা করা যে ক্ষেত্রে, কেন OWASP তালিকাটিতে আপনার প্রশ্নে আপনাকে উল্লেখ করেছে না?
এস। লট

উত্তর:


13

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

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

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

একটি সম্পর্কিত সমস্যা হ'ল একটি বাফারে একটি অক্ষর দ্বারা খুব ছোট লেখার সমস্যা, ভুলে যাওয়া যে সি অক্ষরে লম্বা সি স্ট্রিংটি '\0'টার্মিনেটরের কারণে মেমরিতে n + 1 অক্ষর প্রয়োজন । আক্রমণকারী যদি টার্মিনেটর ছাড়াই স্ট্রিং সংরক্ষণ করতে পারে তবে স্ট্রিংয়ের প্রত্যাশিত যে কোনও সি ফাংশন শূন্য বাইট না ছোঁড়া অবধি প্রক্রিয়াকরণ অব্যাহত রাখবে, যার ফলস্বরূপ কাঙ্ক্ষিত বা তার চেয়ে বেশি তথ্য আউটপুট তৈরি হতে পারে (বা ডস আক্রমণে সুরক্ষিত মেমোরি আঘাত করা) )। সমাধানটি আবার সচেতনতা, যত্ন এবং কোড পর্যালোচনা।

printf()পরিবারের সাথে আরও একটি ঝুঁকি রয়েছে । আপনি যদি কখনও লিখেন char * str; ... printf(str);তবে strমুদ্রণের সময় যদি কোনও '%' থাকে তবে আপনি সমস্যার জন্য নিজেকে প্রস্তুত করছেন । %nবিন্যাস নির্দেশ দেয় printf()মেমরিতে লিখতে। সমাধান হয় printf("%s", str);বা puts(str);। (এছাড়াও এর snprintf()পরিবর্তে C99 ব্যবহার করুন sprintf()))

স্বাক্ষরবিহীন পূর্ণ সংখ্যাগুলি, বিশেষত লুপ সূচক হিসাবে ব্যবহার করা সমস্যার কারণ হতে পারে। আপনি যদি স্বাক্ষরবিহীনকে একটি ছোট নেতিবাচক মান নির্ধারণ করেন তবে আপনি একটি বড় ধনাত্মক মান পাবেন। এটি কেবলমাত্র কোনও এন এর উদাহরণগুলির প্রক্রিয়াকরণের মতো বিষয়গুলিকে বা সীমিত ফাংশনগুলিকে হ্রাস করতে পারে strncpy()। সমস্ত স্বাক্ষরবিহীন পূর্ণসংখ্যা পরীক্ষা করুন। আপনি এড়াতে চাইতে পারেন unsigned short, যেহেতু এর মধ্যে একটিতে একটি বড় মান একটিতে একটি বৃহত ধনাত্মক মানকে রূপান্তরিত করে int

ভুলে যাবেন না যে একটি অক্ষর ধ্রুবক, সি, আসলে একটি int। এর মতো কিছু লেখা char c; while((c = getchar()) != EOF) ...সহজেই ব্যর্থ EOFহতে পারে, যেহেতু এটিতে প্রতিনিধিত্বযোগ্য হবে না char

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


printf("%s", str)যখন puts(str)একই কাজটি করবে তখন নগ্ন স্ট্রিংয়ের জন্য ব্যবহার করার দরকার নেই ।
ব্লারফ্লিল

@ ব্লারফ্লাল কিন্তু putsএকটি নতুন লাইন চরিত্র সংযোজন printfকরেন যখন না হয়।
ডানফোনটি

করতে পারে fputs(str, stdout), যা না।
blrfl

পূর্ণসংখ্যার ওভারফ্লো হিসাবে: সাইন ইনডগুলি ব্যবহার করা কোনও সমাধান নয়, কারণ এগুলি উপচে পড়া UB এর কারণ হবে। একমাত্র (বেদনাদায়ক) সমাধানটি হ'ল আনুষ্ঠানিকভাবে প্রমাণ করুন যে আপনি কখনই উপচে পড়বেন না, বা রানটাইমের সময় চেক করবেন (তবে সঠিকভাবে যাচাই করুন, যা চেকটিতে প্রবাহিত না হয়েও জটিল)।
sleske

@ ডেভিডথর্নলি: বিপজ্জনকতার কারণে সি 11 এবং সি ++ 14 স্ট্যান্ডার্ড সরানো লাইব্রেরি থেকে ফাংশন করে ()।
ধ্বংসকারী

5

সি-নির্দিষ্ট কিছু ঝুঁকির মধ্যে রয়েছে: বাফার ওভারফ্লো , ফর্ম্যাটিং স্ট্রিং আক্রমণ এবং পূর্ণসংখ্যার ওভারফ্লো


1
বাফার ওভারফ্লো সম্পর্কে সি-নির্দিষ্ট কিছুই নেই - পয়েন্টার সহ যে কোনও ভাষাতে এটি থাকতে পারে। পূর্ণসংখ্যার ওভারফ্লোগুলি কেবল যে কোনও ভাষার ক্ষেত্রে প্রযোজ্য, এবং সহজেই পরিচালিত কোডেও ঘটতে পারে।
স্টিভ

1
@ স্টিভ, এটি সত্যই নির্দেশক নয় যা সমস্যার সৃষ্টি করে তবে ভাষা কীভাবে অ্যারে সীমাবদ্ধতা প্রয়োগ করে না।
ডগ টি।

2
@ স্টিভ প্রশ্নটি এমন স্টাফ সম্পর্কে জিজ্ঞাসা করছিল না যা কেবল সি সম্পর্কিত, তবে সি প্রোগ্রামারদের সচেতন হওয়া উচিত এমন কিছু।
অ্যাটাকিংহোব

1
@ স্টিভ: সি প্রচলিত পরিসীমা পরীক্ষা করার পক্ষে সমর্থন না পাওয়ার এবং লাইব্রেরির ক্রিয়াকলাপগুলির সংখ্যার কারণে আপনার পক্ষে বাফার উপচে পড়বে unus
ডেভিড থর্নলি

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

4

ঝুঁকি মিস করার জন্য এখানে একটি সহজ সমস্যা রয়েছে যা সমস্যার সমাধান করতে কয়েক ঘন্টা সময় নিতে পারে।

নিম্নলিখিত কোডটি বিবেচনা করুন, যা কোনও সমস্যা ছাড়াই সংকলন করবে।

if(lpstr_current_state = CONST_EMERGENCY_STATE_HOLY_CRAP)
{
    do_warn_joint_chiefs_of_staff_of_nuclear_attack();
}

যখন আপনি দেখতে চেক যদি lpstr_current_stateহয় CONST_EMERGENCY_STATE_HOLY_CRAPআপনি আসলে বরাদ্দ করছি। সবসময় বাম দিকে ধ্রুবক পরিবর্তনশীল রাখা ভাল। আপনি যখন ধ্রুবকটি বাম দিকে রাখবেন, তখন সংকলকটি ব্যর্থ হবে কারণ আপনি কোনও ভেরিয়েবলের জন্য কোনও মান নির্ধারণ করতে পারবেন না।

if(CONST_EMERGENCY_STATE_HOLY_CRAP = lpstr_current_state)
{
    do_warn_joint_chiefs_of_staff_of_nuclear_attack();
}

তারপরে কোডটি ফিক্স করার সময় আপনি নিজেকে সহজেই বলতে পারেন, "পবিত্র ক্রেপ, এটি খারাপ হতে পারে" ...

if(CONST_EMERGENCY_STATE_HOLY_CRAP == lpstr_current_state)
{
    do_warn_joint_chiefs_of_staff_of_nuclear_attack();
}

7
এটি সংকলককে অন্য কয়েকটি সমস্যার বিপরীতে একটি সতর্কতা হিসাবে ধরা ও ফ্ল্যাগ করা সহজ। দুর্ভাগ্যক্রমে, সমস্ত সংকলকগুলি এটি করা সহজ করে না।
ডেভিড থর্নলি

2
এটি সি ব্যতীত অন্য ভাষায়ও ঘটতে পারে, যে কোনও ভাষা ব্যবহার করে =এবং ==
হতাশিত

3
এটিও সত্যিকারের সুরক্ষার দুর্বলতা নয়, এটি একটি বাগ।
ক্রিস পিটম্যান

1
এগুলিকে যোদা শর্ত বলে।

2
@ ক্রিস্টোফার হচ: আমরা যদি কোনও সম্ভাব্য সি বাগকে ঝুঁকিপূর্ণ হিসাবে ডাকে এবং এখানে এটি বিবেচনা করি তবে আমাদের আরও বৃহত্তর ফোরামের প্রয়োজন হবে।
ডেভিড থর্নলি

0

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

সুতরাং আপনি যখন মনে করেন "তাদের সঠিক মনের কেউ ..." করবে না, তখন আপনাকে তাত্ক্ষণিকভাবে ভাবতে হবে "যদি অন্য লোকের কম্পিউটারগুলিতে হ্যাক করতে চায় এমন ব্যক্তিটি ঠিক তেমন করে তবে"।

সবচেয়ে বড় পরিণতি হ'ল যখনই আপনি বাইরের ইভেন্টগুলিতে প্রতিক্রিয়া দেখান (উদাহরণস্বরূপ, বাইরে থেকে সরবরাহিত ডেটা প্রক্রিয়াকরণ করে), আপনাকে অবশ্যই ধরে নিতে হবে যে এই ডেটাটি আপনার সবচেয়ে খারাপ শত্রুর নিয়ন্ত্রণে ছিল।


যদিও আমি দুই এবং তিন অনুচ্ছেদে সম্মত হব, হামলাকারীর উপর সমস্ত দোষ চাপানো আমার চোখে কিছুটা ঘন। সফল আক্রমণটির জন্য এটি সর্বদা দু'বার লাগে: একজন প্রোগ্রামার যিনি স্ক্রু আপ করেন এবং একটি আক্রমণকারী যিনি এই প্রোগ্রামারে প্রোগ্রামারকে ধরে ফেলেন। তবে, আক্রমণকারী এটি কাজে লাগাতে পারার আগে নিরাপত্তা দুর্বলতা রয়েছে । এবং তার জন্য, প্রোগ্রামারকে দোষ দেওয়া উচিত।
মাস্টার - মোনিকা
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.