আপনার কোডটিতে কখনও হার্ড-কোড পাসওয়ার্ড নেই। সম্প্রতি শীর্ষস্থানীয় 25 সবচেয়ে বিপজ্জনক প্রোগ্রামিং ভুলগুলিতে এটি প্রকাশিত হয়েছিল :
আপনার সফ্টওয়্যারটিতে একটি গোপন অ্যাকাউন্ট এবং পাসওয়ার্ড হার্ড-কোডিং অত্যন্ত সুবিধাজনক - দক্ষ বিপরীত প্রকৌশলীদের জন্য। যদি পাসওয়ার্ডটি আপনার সমস্ত সফ্টওয়্যার জুড়ে একই থাকে, তবে সেই পাসওয়ার্ডটি অনিবার্যভাবে জানা হয়ে গেলে প্রতিটি গ্রাহক দুর্বল হয়ে পড়ে। এবং এটি হার্ড কোডেড হওয়ার কারণে এটি ঠিক করার জন্য একটি বিশাল ব্যথা।
পাসওয়ার্ড সহ আপনার কনফিগারেশন সম্পর্কিত তথ্য পৃথক ফাইলে সংরক্ষণ করা উচিত যা অ্যাপ্লিকেশনটি শুরু হয় reads পচনশীল হওয়ার ফলে পাসওয়ার্ড ফাঁস হওয়া থেকে রোধ করার একমাত্র আসল উপায় (এটি কখনই শুরু করতে বাইনারিতে সংকলন করবেন না)।
এই সাধারণ ভুল সম্পর্কে আরও তথ্যের জন্য, আপনি CWE-259 নিবন্ধটি পড়তে পারেন । নিবন্ধটিতে আরও বিশদ সংজ্ঞা, উদাহরণ এবং সমস্যা সম্পর্কে প্রচুর অন্যান্য তথ্য রয়েছে।
জাভাতে, এটি করার অন্যতম সহজ উপায় হল পছন্দসমূহ ক্লাসটি ব্যবহার করা। এটি সমস্ত ধরণের প্রোগ্রাম সেটিংস সংরক্ষণ করার জন্য ডিজাইন করা হয়েছে, যার মধ্যে একটি ব্যবহারকারীর নাম এবং পাসওয়ার্ড অন্তর্ভুক্ত থাকতে পারে।
import java.util.prefs.Preferences;
public class DemoApplication {
Preferences preferences =
Preferences.userNodeForPackage(DemoApplication.class);
public void setCredentials(String username, String password) {
preferences.put("db_username", username);
preferences.put("db_password", password);
}
public String getUsername() {
return preferences.get("db_username", null);
}
public String getPassword() {
return preferences.get("db_password", null);
}
}
উপরের কোডে, আপনি setCredentialsব্যবহারকারীর নাম এবং পাসওয়ার্ডের জন্য ডায়ালগ জিজ্ঞাসা করার পরে পদ্ধতিটি কল করতে পারেন । আপনার যখন ডাটাবেসের সাথে সংযোগ স্থাপন করতে হবে তখন আপনি সঞ্চিত মানগুলি পুনরুদ্ধার করতে কেবল পদ্ধতি getUsernameএবং getPasswordপদ্ধতিগুলি ব্যবহার করতে পারেন । লগইন শংসাপত্রগুলি আপনার বাইনারিগুলিতে কঠোরভাবে কোড করা হবে না, তাই ক্ষয়করণ কোনও সুরক্ষা ঝুঁকি তৈরি করবে না।
গুরুত্বপূর্ণ দ্রষ্টব্য: পছন্দগুলি ফাইলগুলি কেবলমাত্র সরল পাঠ্য এক্সএমএল ফাইল। অননুমোদিত ব্যবহারকারীদের কাঁচা ফাইল (ইউনিক্স অনুমতি, উইন্ডোজ অনুমতি এবং ইত্যাদি) দেখতে বাধা দেওয়ার জন্য আপনি যথাযথ পদক্ষেপ নিয়েছেন তা নিশ্চিত করুন। লিনাক্সে, কমপক্ষে, এটি কোনও সমস্যা নয়, কারণ কলিং Preferences.userNodeForPackageবর্তমান ব্যবহারকারীর হোম ডিরেক্টরিতে এক্সএমএল ফাইল তৈরি করবে, যা অন্য ব্যবহারকারীদের দ্বারা যেভাবেই পঠনযোগ্য নয়। উইন্ডোজে পরিস্থিতি আলাদা হতে পারে।
আরও গুরুত্বপূর্ণ নোট: এই অবস্থার জন্য সঠিক স্থাপত্যটি কী তা নিয়ে এই উত্তর এবং অন্যদের মন্তব্যগুলিতে প্রচুর আলোচনা হয়েছে। আসল প্রশ্নটিতে প্রকৃতপক্ষে প্রসঙ্গটি উল্লেখ করা হয়নি যেখানে অ্যাপ্লিকেশনটি ব্যবহৃত হচ্ছে, তাই আমি যে দুটি পরিস্থিতি নিয়ে ভাবতে পারি সে সম্পর্কে কথা বলব। প্রথমটি হল সেই ক্ষেত্রে যেখানে প্রোগ্রামটি ব্যবহার করা ব্যক্তি ইতিমধ্যে ডেটাবেস শংসাপত্রগুলি জানেন (এবং এটি জানার জন্য অনুমোদিত)। দ্বিতীয়টি হ'ল সেই ক্ষেত্রে আপনি, বিকাশকারী, প্রোগ্রামটি ব্যবহার করে ব্যক্তির কাছ থেকে ডাটাবেস শংসাপত্রগুলি গোপন রাখার চেষ্টা করছেন।
প্রথম কেস: ব্যবহারকারী ডাটাবেস লগইন শংসাপত্রগুলি জানার জন্য অনুমোদিত is
এই ক্ষেত্রে, আমি উপরে উল্লিখিত সমাধানটি কাজ করবে। জাভা Preferenceক্লাসটি ব্যবহারকারীর নাম এবং পাসওয়ার্ড সরল পাঠ্যে সংরক্ষণ করবে, তবে পছন্দসই ফাইলটি কেবল অনুমোদিত ব্যবহারকারী দ্বারা পঠনযোগ্য। ব্যবহারকারী কেবল পছন্দসমূহের এক্সএমএল ফাইলটি খুলতে এবং লগইন শংসাপত্রগুলি পড়তে পারে, তবে এটি কোনও সুরক্ষা ঝুঁকি নয় কারণ ব্যবহারকারী শংসাপত্রগুলি শুরু করার বিষয়টি জানতেন।
দ্বিতীয় কেস: ব্যবহারকারীর কাছ থেকে লগইন শংসাপত্রগুলি আড়াল করার চেষ্টা করা হচ্ছে
এটি আরও জটিল কেস: ব্যবহারকারীর লগইন শংসাপত্রগুলি জানা উচিত নয় তবে তবুও ডাটাবেসে অ্যাক্সেস প্রয়োজন। এই ক্ষেত্রে, অ্যাপ্লিকেশনটি ব্যবহারকারী ব্যবহারকারীর ডাটাবেসে সরাসরি অ্যাক্সেস রয়েছে যার অর্থ প্রোগ্রামের আগে লগইন শংসাপত্রগুলি জানতে হবে know আমি উপরে উল্লিখিত সমাধানটি এই ক্ষেত্রে উপযুক্ত নয়। আপনি একটি পছন্দসই ফাইলে ডাটাবেস লগইন শংসাপত্রগুলি সংরক্ষণ করতে পারেন তবে তিনি ব্যবহারকারী সেই ফাইলটি পড়তে সক্ষম হবেন, যেহেতু তারা মালিক হবেন। প্রকৃতপক্ষে, এই কেসটিকে নিরাপদ উপায়ে ব্যবহার করার পক্ষে সত্যিকারের কোনও ভাল উপায় নেই।
সঠিক কেস: একটি বহু-স্তরীয় আর্কিটেকচার ব্যবহার করে
এটি করার সঠিক উপায় হ'ল আপনার ডাটাবেস সার্ভার এবং আপনার ক্লায়েন্ট অ্যাপ্লিকেশনের মধ্যে একটি মাঝারি স্তর থাকা যা পৃথক ব্যবহারকারীদের প্রমাণীকরণ করে এবং সীমিত ক্রিয়াকলাপ সম্পাদনের অনুমতি দেয়। প্রতিটি ব্যবহারকারীর নিজস্ব লগইন শংসাপত্র থাকবে, তবে ডাটাবেস সার্ভারের জন্য নয়। শংসাপত্রগুলি মধ্য স্তর (ব্যবসায়িক লজিক স্তর) অ্যাক্সেসের অনুমতি দেয় এবং প্রতিটি ব্যবহারকারীর জন্য পৃথক হতে পারে।
প্রত্যেক ব্যবহারকারীর নিজস্ব ব্যবহারকারীর নাম এবং পাসওয়ার্ড থাকবে যা কোনও সুরক্ষা ঝুঁকি ছাড়াই স্থানীয়ভাবে একটি পছন্দ ফাইলগুলিতে সংরক্ষণ করা যেতে পারে। একে ত্রি-স্তরের আর্কিটেকচার বলা হয় (স্তরগুলি আপনার ডাটাবেস সার্ভার, ব্যবসায় লজিক সার্ভার এবং ক্লায়েন্ট অ্যাপ্লিকেশন)। এটি আরও জটিল, তবে এই ধরণের জিনিসটি করা সবচেয়ে নিরাপদ উপায়।
ক্রিয়াকলাপের মূল ক্রমটি হ'ল:
- ক্লায়েন্ট ব্যবহারকারীর ব্যক্তিগত ব্যবহারকারীর নাম / পাসওয়ার্ড ব্যবহার করে ব্যবসায় যুক্তিযুক্ত স্তরের সাথে প্রমাণীকরণ করে। ব্যবহারকারীর নাম এবং পাসওয়ার্ড ব্যবহারকারীর কাছে পরিচিত এবং কোনওভাবেই ডাটাবেস লগইন শংসাপত্রগুলির সাথে সম্পর্কিত নয়।
- যদি প্রমাণীকরণটি সফল হয়, ক্লায়েন্টটি ব্যবসায়িক লজিক স্তরে ডেটাবেস থেকে কিছু তথ্য চেয়ে একটি অনুরোধ করে। উদাহরণস্বরূপ, পণ্যগুলির একটি জায়। নোট করুন যে ক্লায়েন্টের অনুরোধটি কোনও এসকিউএল কোয়েরি নয়; এটি যেমন একটি দূরবর্তী প্রক্রিয়া কল
getInventoryList।
- ব্যবসায়ের লজিক স্তরটি ডাটাবেসের সাথে সংযুক্ত হয় এবং অনুরোধ করা তথ্য পুনরুদ্ধার করে। ব্যবসায়ের লজিক স্তরটি ব্যবহারকারীর অনুরোধের ভিত্তিতে একটি সুরক্ষিত এসকিউএল কোয়েরি গঠনের দায়িত্বে থাকে। এসকিউএল কোয়েরির কোনও পরামিতি এসকিউএল ইনজেকশন আক্রমণ রোধ করতে স্যানিটাইজ করা উচিত।
- ব্যবসায়ের লজিক স্তর ক্লায়েন্ট অ্যাপ্লিকেশনটিতে তালিকা তালিকাটি প্রেরণ করে।
- ক্লায়েন্ট ব্যবহারকারীদের জন্য তালিকা তালিকা প্রদর্শন করে।
নোট করুন যে পুরো প্রক্রিয়াতে, ক্লায়েন্ট অ্যাপ্লিকেশন কখনই সরাসরি ডাটাবেসের সাথে সংযুক্ত হয় না । ব্যবসায়ের লজিক স্তরটি কোনও প্রমাণীকৃত ব্যবহারকারীর কাছ থেকে একটি অনুরোধ গ্রহণ করে, তালিকা তালিকার জন্য ক্লায়েন্টের অনুরোধটি প্রক্রিয়া করে এবং কেবলমাত্র তখনই একটি এসকিউএল কোয়েরি কার্যকর করে।