جاوا میں سیکیورٹی: بہترین طریقے

سرور ایپلی کیشنز میں سب سے اہم میٹرکس میں سے ایک سیکیورٹی ہے۔ یہ ایک قسم کی غیر فعال ضرورت ہے ۔ سیکیورٹی میں بہت سے اجزاء شامل ہیں۔ بلاشبہ، تمام معلوم حفاظتی اصولوں اور حفاظتی اقدامات کا مکمل احاطہ کرنے میں ایک سے زیادہ مضمون درکار ہوں گے، لہذا ہم سب سے اہم پر غور کریں گے۔ اس موضوع میں مہارت رکھنے والا شخص تمام متعلقہ عمل کو ترتیب دے سکتا ہے، نئے حفاظتی سوراخ پیدا کرنے سے بچ سکتا ہے، اور کسی بھی ٹیم کو اس کی ضرورت ہوگی۔ یقیناً، آپ کو یہ نہیں سوچنا چاہیے کہ اگر آپ ان طریقوں پر عمل کرتے ہیں تو آپ کی درخواست 100% محفوظ ہوگی۔ نہیں! لیکن یہ یقینی طور پر ان کے ساتھ زیادہ محفوظ ہوگا۔ چلو.

1. جاوا زبان کی سطح پر سیکیورٹی فراہم کریں۔

سب سے پہلے، جاوا میں سیکیورٹی زبان کی صلاحیتوں کی سطح سے شروع ہوتی ہے۔ اگر رسائی میں ترمیم کرنے والے نہ ہوتے تو ہم کیا کریں گے؟ انارکی کے سوا کچھ نہ ہوگا۔ پروگرامنگ لینگویج محفوظ کوڈ لکھنے میں ہماری مدد کرتی ہے اور بہت سی مضمر حفاظتی خصوصیات کا استعمال بھی کرتی ہے:

1. مضبوط ٹائپنگ۔ جاوا ایک مستحکم طور پر ٹائپ شدہ زبان ہے۔ اس سے رن ٹائم کے وقت قسم سے متعلق غلطیوں کو پکڑنا ممکن ہو جاتا ہے۔
2. ترمیم کرنے والوں تک رسائی۔ یہ ہمیں ضرورت کے مطابق کلاسز، طریقوں اور فیلڈز تک رسائی کو اپنی مرضی کے مطابق کرنے کی اجازت دیتے ہیں۔
3. خودکار میموری کا انتظام۔ اس کے لیے جاوا ڈویلپرز کے پاس کوڑا اٹھانے والا ہے جو ہمیں ہر چیز کو دستی طور پر ترتیب دینے سے آزاد کرتا ہے۔ ہاں، بعض اوقات مسائل پیدا ہوتے ہیں۔
4. بائٹ کوڈ کی توثیق : جاوا کو بائیک کوڈ میں مرتب کیا جاتا ہے، جس پر عمل درآمد سے پہلے رن ٹائم کے ذریعے جانچ پڑتال کی جاتی ہے۔

مزید برآں، اوریکل کی حفاظتی سفارشات ہیں ۔ بے شک، یہ بلند زبان میں نہیں لکھا گیا ہے اور آپ اسے پڑھتے ہوئے کئی بار سو سکتے ہیں، لیکن یہ اس کے قابل ہے۔ خاص طور پر، جاوا SE کے لیے محفوظ کوڈنگ گائیڈ لائنز کے عنوان سے دستاویز اہم ہے۔ یہ محفوظ کوڈ لکھنے کے طریقے کے بارے میں مشورہ فراہم کرتا ہے۔ یہ دستاویز بہت زیادہ مفید معلومات فراہم کرتی ہے۔ اگر آپ کو موقع ملے تو آپ اسے ضرور پڑھیں۔ اس مواد میں اپنی دلچسپی بڑھانے کے لیے، یہاں چند دلچسپ تجاویز ہیں:

1. سیکیورٹی سے متعلق حساس کلاسوں کو سیریلائز کرنے سے گریز کریں۔ سیریلائزیشن سیریلائزڈ فائل میں کلاس انٹرفیس کو بے نقاب کرتی ہے، سیریلائزڈ ڈیٹا کا ذکر نہیں کرنا۔
2. ڈیٹا کے لیے متغیر کلاسوں سے بچنے کی کوشش کریں۔ یہ ناقابل تغیر کلاسز کے تمام فوائد فراہم کرتا ہے (مثلاً تھریڈ سیفٹی)۔ اگر آپ کے پاس کوئی متغیر آبجیکٹ ہے تو یہ غیر متوقع رویے کا باعث بن سکتا ہے۔
3. واپس آنے والی تغیر پذیر اشیاء کی کاپیاں بنائیں۔ اگر کوئی طریقہ کسی اندرونی تغیر پذیر آبجیکٹ کا حوالہ واپس کرتا ہے، تو کلائنٹ کوڈ آبجیکٹ کی اندرونی حالت کو بدل سکتا ہے۔
4. اور اسی طرح…

بنیادی طور پر، Java SE کے لیے Secure Coding Guidelines جاوا کوڈ کو صحیح اور محفوظ طریقے سے کیسے لکھنا ہے اس بارے میں تجاویز اور چالوں کا مجموعہ ہے۔

2. ایس کیو ایل انجیکشن کی کمزوریوں کو ختم کریں۔

یہ ایک خاص قسم کی کمزوری ہے۔ یہ خاص ہے کیونکہ یہ سب سے مشہور اور سب سے زیادہ عام خطرات میں سے ایک ہے۔ اگر آپ کو کمپیوٹر سیکیورٹی میں کبھی دلچسپی نہیں رہی ہے، تو آپ کو اس کے بارے میں معلوم نہیں ہوگا۔ ایس کیو ایل انجیکشن کیا ہے؟ یہ ایک ڈیٹا بیس حملہ ہے جس میں اضافی ایس کیو ایل کوڈ انجیکشن لگانا شامل ہے جہاں اس کی توقع نہیں کی جاتی ہے۔ فرض کریں کہ ہمارے پاس ایک طریقہ ہے جو ڈیٹا بیس سے استفسار کرنے کے لیے کسی قسم کے پیرامیٹر کو قبول کرتا ہے۔ مثال کے طور پر، صارف نام۔ کمزور کوڈ کچھ اس طرح نظر آئے گا:

// This method retrieves from the database all users with a certain name
public List findByFirstName(String firstName) throws SQLException {
   // Connect to the database
   Connection connection = DriverManager.getConnection(DB_URL, USER, PASS);

   // Compose a SQL database query with our firstName
   String query = "SELECT * FROM USERS WHERE firstName = " + firstName;

   // Execute the query
   Statement statement = connection.createStatement();
   ResultSet result = statement.executeQuery(query);

   // Use mapToUsers to convert the ResultSet into a collection of users.
   return mapToUsers(result);
}

private List mapToUsers(ResultSet resultSet) {
   // Converts to a collection of users
}

اس مثال میں، ایک SQL استفسار ایک علیحدہ لائن پر پیشگی تیار کیا جاتا ہے۔ تو کیا مسئلہ ہے، ٹھیک ہے؟ شاید مسئلہ یہ ہے کہ String.format کو استعمال کرنا بہتر ہوگا ؟ نہیں؟ ٹھیک ہے، پھر کیا؟ آئیے خود کو ٹیسٹر کے جوتے میں ڈالتے ہیں اور سوچتے ہیں کہ firstName کی قدر کے طور پر کیا پاس کیا جا سکتا ہے ۔ مثال کے طور پر:

1. ہم جس چیز کی توقع کی جاتی ہے اسے پاس کر سکتے ہیں — ایک صارف نام۔ پھر ڈیٹا بیس تمام صارفین کو اس نام کے ساتھ واپس کر دے گا۔
2. ہم ایک خالی سٹرنگ پاس کر سکتے ہیں۔ پھر تمام صارفین کو واپس کر دیا جائے گا۔
3. لیکن ہم درج ذیل کو بھی پاس کر سکتے ہیں: "'; DROP TABLE USERS;"۔ اور یہاں اب ہمیں مسائل کا سامنا ہے۔ یہ استفسار ڈیٹا بیس سے ایک ٹیبل کو حذف کر دے گا۔ تمام اعداد و شمار کے ساتھ۔ سارے کا سارا.

کیا آپ ان مسائل کا تصور کر سکتے ہیں جو اس کی وجہ سے ہوں گے؟ اس سے آگے، آپ جو چاہیں لکھ سکتے ہیں۔ آپ تمام صارفین کے نام تبدیل کر سکتے ہیں۔ آپ ان کے پتے حذف کر سکتے ہیں۔ تخریب کاری کی گنجائش بہت زیادہ ہے۔ اس سے بچنے کے لیے، آپ کو ریڈی میڈ استفسار کے انجیکشن کو روکنے کی ضرورت ہے اور اس کے بجائے پیرامیٹرز کا استعمال کرتے ہوئے استفسار کو تشکیل دینا ہوگا۔ ڈیٹا بیس کے سوالات بنانے کا یہ واحد طریقہ ہونا چاہیے۔ اس طرح آپ اس کمزوری کو ختم کر سکتے ہیں۔ مثال کے طور پر:

// This method retrieves from the database all users with a certain name
public List findByFirstName(String firstName) throws SQLException {
   // Connect to the database
   Connection connection = DriverManager.getConnection(DB_URL, USER, PASS);

   // Create a parameterized query.
   String query = "SELECT * FROM USERS WHERE firstName = ?";

   // Create a prepared statement with the parameterized query
   PreparedStatement statement = connection.prepareStatement(query);

   // Pass the parameter's value
   statement.setString(1, firstName);

   // Execute the query
   ResultSet result = statement.executeQuery(query);

   // Use mapToUsers to convert the ResultSet into a collection of users.
   return mapToUsers(result);
}

private List mapToUsers(ResultSet resultSet) {
   // Converts to a collection of users
}

اس طرح خطرے سے بچا جاتا ہے۔ ان لوگوں کے لیے جو اس مضمون کی گہرائی میں جانا چاہتے ہیں، یہاں ایک بہترین مثال ہے ۔ جب آپ اس کمزوری کو سمجھتے ہیں تو آپ کیسے جانتے ہیں؟ اگر آپ کو ذیل میں مزاحیہ لطیفہ ملتا ہے، تو آپ کو شاید اس بات کا واضح اندازہ ہو جائے گا کہ یہ کمزوری کیا ہے: D

3. انحصار اسکین کریں اور انہیں اپ ڈیٹ رکھیں

اس کا کیا مطلب ہے؟ اگر آپ نہیں جانتے کہ انحصار کیا ہے تو میں وضاحت کروں گا۔ انحصار ایک JAR آرکائیو ہے جس میں کوڈ ہوتا ہے جو کسی اور کے حل کو دوبارہ استعمال کرنے کے لیے خودکار بلڈ سسٹم (Maven، Gradle، Ant) کا استعمال کرتے ہوئے کسی پروجیکٹ سے منسلک ہوتا ہے۔ مثال کے طور پر، پروجیکٹ لومبوک ، جو رن ٹائم میں ہمارے لیے گیٹرز، سیٹرز وغیرہ تیار کرتا ہے۔ بڑی ایپلی کیشنز میں بہت زیادہ اور بہت زیادہ انحصار ہو سکتا ہے۔ کچھ عبوری ہوتے ہیں (یعنی ہر انحصار کا اپنا انحصار ہوسکتا ہے، وغیرہ)۔ نتیجے کے طور پر، حملہ آور اوپن سورس کے انحصار پر تیزی سے توجہ دے رہے ہیں، کیونکہ وہ باقاعدگی سے استعمال ہوتے ہیں اور بہت سے کلائنٹس کو ان کی وجہ سے مسائل کا سامنا کرنا پڑ سکتا ہے۔ یہ یقینی بنانا ضروری ہے کہ پورے انحصار کے درخت میں کوئی معلوم کمزوریاں نہیں ہیں (ہاں، یہ ایک درخت کی طرح لگتا ہے)۔ ایسا کرنے کے کئی طریقے ہیں۔

انحصار کی نگرانی کے لیے Snyk استعمال کریں۔

Snyk پراجیکٹ کے تمام انحصارات اور معلوم خطرات کو چیک کرتا ہے۔ آپ Snyk پر رجسٹر ہو سکتے ہیں اور اپنے پروجیکٹس کو GitHub کے ذریعے درآمد کر سکتے ہیں۔ اس کے علاوہ، جیسا کہ آپ اوپر دی گئی تصویر سے دیکھ سکتے ہیں، اگر کسی نئے ورژن میں کمزوری کو ٹھیک کیا جاتا ہے، تو Snyk اسے ٹھیک کرنے کی پیشکش کرے گا اور پل کی درخواست تیار کرے گا۔ آپ اسے اوپن سورس پروجیکٹس کے لیے مفت استعمال کر سکتے ہیں۔ پروجیکٹس کو باقاعدہ وقفوں پر اسکین کیا جاتا ہے، جیسے ہفتے میں ایک بار، مہینے میں ایک بار۔ میں نے اپنے تمام عوامی ذخیروں کو Snyk اسکین میں رجسٹر کیا اور شامل کیا (اس میں کوئی خطرناک بات نہیں ہے، کیونکہ یہ پہلے ہی سب کے لیے عوامی ہیں)۔ Snyk نے پھر اسکین کا نتیجہ دکھایا: اور تھوڑی دیر کے بعد، Snyk-bot نے ان پروجیکٹس میں کئی پل درخواستیں تیار کیں جہاں انحصار کو اپ ڈیٹ کرنے کی ضرورت ہے: اور یہ بھی: یہ نئے ورژنز کے لیے کمزوریوں کو تلاش کرنے اور اپ ڈیٹس کی نگرانی کے لیے ایک بہترین ٹول ہے۔

GitHub سیکیورٹی لیب استعمال کریں۔

GitHub پر کام کرنے والا کوئی بھی شخص اس کے بلٹ ان ٹولز سے فائدہ اٹھا سکتا ہے۔ آپ GitHub Security Lab کا اعلان کرنے کے عنوان سے ان کی بلاگ پوسٹ میں اس نقطہ نظر کے بارے میں مزید پڑھ سکتے ہیں ۔ یہ ٹول، یقیناً، Snyk سے آسان ہے، لیکن آپ کو یقینی طور پر اسے نظرانداز نہیں کرنا چاہیے۔ مزید یہ کہ معلوم کمزوریوں کی تعداد صرف بڑھے گی، اس لیے Snyk اور GitHub سیکیورٹی لیب دونوں توسیع اور بہتری کو جاری رکھیں گے۔

سوناٹائپ ڈیپ شیلڈ کو فعال کریں۔

اگر آپ اپنے ذخیروں کو ذخیرہ کرنے کے لیے GitHub کا استعمال کرتے ہیں، تو آپ اپنے پروجیکٹس میں Sonatype DepShield، مارکیٹ پلیس میں موجود ایپلی کیشنز میں سے ایک کو شامل کر سکتے ہیں۔ اسے انحصار کے لیے پروجیکٹس کو اسکین کرنے کے لیے بھی استعمال کیا جا سکتا ہے۔ مزید برآں، اگر اسے کچھ مل جاتا ہے، تو ایک مناسب تفصیل کے ساتھ ایک GitHub مسئلہ تیار کیا جائے گا جیسا کہ ذیل میں دکھایا گیا ہے:

4. خفیہ ڈیٹا کو احتیاط سے ہینڈل کریں۔

ہم متبادل طور پر "حساس ڈیٹا" کا جملہ استعمال کر سکتے ہیں۔ گاہک کی ذاتی معلومات، کریڈٹ کارڈ نمبرز، اور دیگر حساس معلومات کا لیک ہونا ناقابل تلافی نقصان کا باعث بن سکتا ہے۔ سب سے پہلے، اپنی درخواست کے ڈیزائن پر گہری نظر ڈالیں اور اس بات کا تعین کریں کہ آیا آپ کو واقعی اس یا اس ڈیٹا کی ضرورت ہے۔ شاید آپ کو درحقیقت آپ کے پاس موجود کچھ ڈیٹا کی ضرورت نہ ہو — وہ ڈیٹا جو مستقبل کے لیے شامل کیا گیا تھا جو نہیں آیا اور آنے کا امکان نہیں ہے۔ مزید برآں، آپ بہت سے لوگ نادانستہ طور پر ایسے ڈیٹا کو لاگنگ کے ذریعے لیک کر دیتے ہیں۔ حساس ڈیٹا کو اپنے لاگز میں داخل ہونے سے روکنے کا ایک آسان طریقہ یہ ہے کہ toString() ڈومین اداروں (جیسے صارف، طالب علم، استاد وغیرہ) کے طریقوں کو صاف کریں ۔ یہ آپ کو اتفاقی طور پر خفیہ فیلڈز کو آؤٹ پٹ کرنے سے روکے گا۔ اگر آپ toString() طریقہ بنانے کے لیے Lombok کا استعمال کرتے ہیں، تو آپ @ToString.Exclude تشریح استعمال کر سکتے ہیں تاکہ toString() طریقہ کے آؤٹ پٹ میں کسی فیلڈ کو استعمال ہونے سے روکا جا سکے ۔ اس کے علاوہ، بیرونی دنیا کو ڈیٹا بھیجتے وقت بہت محتاط رہیں۔ فرض کریں کہ ہمارے پاس ایک HTTP اینڈ پوائنٹ ہے جو تمام صارفین کے نام دکھاتا ہے۔ صارف کی منفرد داخلی ID دکھانے کی ضرورت نہیں ہے۔ کیوں؟ کیونکہ حملہ آور اسے صارف کے بارے میں دیگر، زیادہ حساس معلومات حاصل کرنے کے لیے استعمال کر سکتا ہے۔ مثال کے طور پر، اگر آپ JSON سے/سے POJO کو سیریلائز/ڈی سیریلائز کرنے کے لیے جیکسن کا استعمال کرتے ہیں ، تو آپ مخصوص فیلڈز کی سیریلائزیشن/ڈی سیریلائزیشن کو روکنے کے لیے @JsonIgnore اور @JsonIgnoreProperties تشریحات استعمال کر سکتے ہیں۔ عام طور پر، آپ کو مختلف جگہوں پر مختلف POJO کلاسز استعمال کرنے کی ضرورت ہے۔ اس کا کیا مطلب ہے؟

1. ڈیٹا بیس کے ساتھ کام کرتے وقت، ایک قسم کا POJO (ایک ادارہ) استعمال کریں۔
2. کاروباری منطق کے ساتھ کام کرتے وقت، ایک ہستی کو ماڈل میں تبدیل کریں۔
3. بیرونی دنیا کے ساتھ کام کرتے وقت اور HTTP درخواستیں بھیجتے وقت، مختلف اداروں (DTOs) کا استعمال کریں۔

اس طرح آپ واضح طور پر وضاحت کر سکتے ہیں کہ کون سے فیلڈز باہر سے نظر آئیں گے اور کون سے نہیں۔

مضبوط انکرپشن اور ہیشنگ الگورتھم استعمال کریں۔

صارفین کا خفیہ ڈیٹا محفوظ طریقے سے محفوظ کیا جانا چاہیے۔ ایسا کرنے کے لیے، ہمیں انکرپشن استعمال کرنے کی ضرورت ہے۔ کام پر منحصر ہے، آپ کو یہ فیصلہ کرنے کی ضرورت ہے کہ کس قسم کی خفیہ کاری کو استعمال کرنا ہے۔ مزید برآں، مضبوط انکرپشن میں زیادہ وقت لگتا ہے، اس لیے آپ کو دوبارہ غور کرنے کی ضرورت ہے کہ اس کی ضرورت اس پر صرف کیے گئے وقت کو کتنی درست ثابت کرتی ہے۔ یقیناً، آپ خود ایک انکرپشن الگورتھم لکھ سکتے ہیں۔ لیکن یہ غیر ضروری ہے۔ آپ اس علاقے میں موجودہ حل استعمال کرسکتے ہیں۔ مثال کے طور پر، Google Tink :

<!-- https://mvnrepository.com/artifact/com.google.crypto.tink/tink -->
<dependency>
   <groupid>com.google.crypto.tink</groupid>
   <artifactid>tink</artifactid>
   <version>1.3.0</version>
</dependency>

آئیے دیکھتے ہیں کہ کیا کرنا ہے، اس مثال کا استعمال کرتے ہوئے جس میں انکرپشن اور ڈکرپشن شامل ہے:

private static void encryptDecryptExample() {
   AeadConfig.register();
   KeysetHandle handle = KeysetHandle.generateNew(AeadKeyTemplates.AES128_CTR_HMAC_SHA256);

   String plaintext = "Elvis lives!";
   String aad = "Buddy Holly";

   Aead aead = handle.getPrimitive(Aead.class);
   byte[] encrypted = aead.encrypt(plaintext.getBytes(), aad.getBytes());
   String encryptedString = Base64.getEncoder().encodeToString(encrypted);
   System.out.println(encryptedString);

   byte[] decrypted = aead.decrypt(Base64.getDecoder().decode(encrypted), aad.getBytes());
   System.out.println(new String(decrypted));
}

پاس ورڈز کو خفیہ کرنا

اس کام کے لیے، غیر متناسب خفیہ کاری کا استعمال کرنا سب سے محفوظ ہے۔ کیوں؟ کیونکہ ایپلیکیشن کو واقعی پاس ورڈ کو ڈکرپٹ کرنے کی ضرورت نہیں ہے۔ یہ معیاری طریقہ ہے۔ حقیقت میں، جب کوئی صارف پاس ورڈ داخل کرتا ہے، تو سسٹم اسے خفیہ کرتا ہے اور اس کا موازنہ پاس ورڈ اسٹور میں موجود چیزوں سے کرتا ہے۔ ایک ہی خفیہ کاری کا عمل انجام دیا جاتا ہے، لہذا ہم توقع کر سکتے ہیں کہ وہ مماثل ہوں گے، اگر درست پاس ورڈ درج کیا گیا ہے، یقیناً :) BCrypt اور SCrypt یہاں موزوں ہیں۔ دونوں کمپیوٹیشنل پیچیدہ الگورتھم کے ساتھ یک طرفہ فنکشنز (کرپٹوگرافک ہیشز) ہیں جن میں کافی وقت لگتا ہے۔ یہ بالکل وہی ہے جس کی ہمیں ضرورت ہے، کیونکہ براہ راست حسابات ہمیشہ کے لئے لگیں گے (اچھی طرح، ایک طویل، طویل وقت). اسپرنگ سیکیورٹی الگورتھم کی پوری رینج کو سپورٹ کرتی ہے۔ ہم SCryptPasswordEncoder اور BCryptPasswordEncoder استعمال کر سکتے ہیں ۔ جسے فی الحال ایک مضبوط انکرپشن الگورتھم سمجھا جاتا ہے اسے اگلے سال کمزور سمجھا جا سکتا ہے۔ نتیجے کے طور پر، ہم یہ نتیجہ اخذ کرتے ہیں کہ ہمیں اپنے استعمال کردہ الگورتھم کو باقاعدگی سے چیک کرنا چاہیے اور ضرورت کے مطابق ان لائبریریوں کو اپ ڈیٹ کرنا چاہیے جن میں انکرپشن الگورتھم شامل ہیں۔

نتیجہ اخذ کرنے کے بجائے

آج ہم نے سیکورٹی کے بارے میں بات کی اور قدرتی طور پر بہت سی چیزیں پردے کے پیچھے رہ گئیں۔ میں نے ابھی آپ کے لیے ایک نئی دنیا کا دروازہ کھولا ہے، ایک ایسی دنیا جس کی اپنی زندگی ہے۔ سیکیورٹی بالکل سیاست کی طرح ہے: اگر آپ خود کو سیاست میں مصروف نہیں کرتے ہیں تو سیاست آپ کے ساتھ خود کو مصروف کردے گی۔ میں روایتی طور پر تجویز کرتا ہوں کہ آپ مجھے GitHub اکاؤنٹ پر فالو کریں ۔ وہاں میں اپنی تخلیقات پوسٹ کرتا ہوں جن میں مختلف ٹیکنالوجیز شامل ہیں جن کا میں مطالعہ کر رہا ہوں اور کام پر درخواست دے رہا ہوں۔

مفید لنکس

1. گرو99: ایس کیو ایل انجیکشن ٹیوٹوریل
2. اوریکل: جاوا سیکیورٹی ریسورس سینٹر
3. اوریکل: جاوا SE کے لیے محفوظ کوڈنگ کے رہنما خطوط
4. Baeldung: جاوا سیکیورٹی کی بنیادی باتیں
5. میڈیم: آپ کی جاوا سیکیورٹی کو طاقتور بنانے کے لیے 10 نکات
6. Snyk: 10 جاوا سیکیورٹی کے بہترین طریقے
7. GitHub: GitHub سیکیورٹی لیب کا اعلان: دنیا کے کوڈ کو ایک ساتھ محفوظ کرنا