Node.js டெவலப்பர்கள் Production-க்கு கொண்டு செல்லும் பாதுகாப்புப் பிழைகள்
கடந்த ஆண்டு ஒரு ஸ்டார்ட்அப் நிறுவனத்தின் குறியீட்டை (code) நான் ஆய்வு செய்தேன். அந்த குறியீடு சுத்தமாகத் தெரிந்தது. சோதனைகளும் (tests) வெற்றிகரமாக முடிந்தன.
பிறகு நான் இந்த வரியைப் பார்த்தேன்:
const query = SELECT * FROM users WHERE email = '${req.body.email}'``
இது ஒரு SQL injection பிழை. அந்த ஸ்டார்ட்அப் நிறுவனம் இதை 8 மாதங்களாக production-இல் இயக்கி வந்தது. எந்த டெவலப்பரோ அல்லது CTO-வோ இதைக் கண்டறியவில்லை.
இந்த பிழைகள் கண்ணுக்குத் தெரியாதவை, ஏனெனில் குறியீடு சரியாக வேலை செய்கிறது. ஒரு பயனர் உள்ளீட்டுப் புலத்தில் (input field) ஒரு தீய கட்டளையைத் தட்டச்சு செய்யும் வரை இது சரியாகவே இயங்கும்.
இந்த 5 பொதுவான தவறுகளைத் தவிர்க்கவும்:
- பயனர் உள்ளீட்டுடன் கூடிய Raw SQL வினவல்களுக்கு (queries) template literals-ஐப் பயன்படுத்த வேண்டாம். இது தாக்குபவர்கள் உங்கள் தரவுத்தளத்தை (database) அணுக வழிவகுக்கும்.
- தவறு:
const query =SELECT * FROM users WHERE email = '${email}'`` - சரி: Parameterized queries-ஐப் பயன்படுத்தவும்.
const query = 'SELECT * FROM users WHERE email = $1'db.query(query, [email])
Git-இல் ரகசியங்களை கசியவிடுதல் டெவலப்பர்கள் பெரும்பாலும்
.envகோப்புகளைத் தங்கள் களஞ்சியங்களில் (repositories) commit செய்கிறார்கள். இது உங்கள் database URLs மற்றும் API keys-களை வெளிச்சத்திற்கு கொண்டு வரும். எப்போதும் உங்கள்.gitignoreகோப்பில்.env-ஐச் சேர்க்கவும்.jwt.verify-க்கு பதிலாக jwt.decode-ஐப் பயன்படுத்துதல்
jwt.decodeடோக்கனைப் படிக்க மட்டுமே செய்யும். அந்த டோக்கன் உண்மையானதா என்பதை அது சரிபார்க்காது. யாராலும் ஒரு போலி டோக்கனை உருவாக்க முடியும்.
- தவறு:
const user = jwt.decode(token) - சரி: எப்போதும் கையொப்பத்தைச் (signature) சரிபார்க்கவும்.
const user = jwt.verify(token, process.env.JWT_SECRET)
- auth endpoints-களில் rate limiting இல்லாமை Rate limiting இல்லையென்றால், தாக்குபவர்கள் brute force மூலம் மில்லியன் கணக்கான கடவுச்சொற்களை முயற்சிக்க முடியும். லாகின் முயற்சிகளைக் கட்டுப்படுத்த ஒரு library-ஐப் பயன்படுத்தவும்.
- சரி: 15 நிமிடங்களுக்கு 10 முயற்சிகள் என்ற அளவில் வரம்பை நிர்ணயிக்கவும்.
- விரிவான பிழைச் செய்திகள் (Verbose error messages) கிளையண்டிற்கு (client) நேரடி பிழைச் செய்திகளை அனுப்புவது, தாக்குபவர்கள் உங்கள் அமைப்பை (system) புரிந்துகொள்ள உதவும். அவர்கள் உங்கள் அட்டவணைப் பெயர்களையும் (table names) தரவுத்தள வகைகளையும் பார்த்துவிடுவார்கள்.
- தவறு:
res.status(500).json({ error: error.message }) - சரி: பிழையை உள்நாட்டிலேயே (internally) பதிவு செய்யவும் (log). பயனருக்கு ஒரு பொதுவான செய்தியை மட்டும் அனுப்பவும்.
res.status(500).json({ error: 'Something went wrong' })
ஒரு endpoint-ஐ வெளியிடுவதற்கு முன், இந்த ஒரு கேள்வியைக் கேளுங்கள்: ஒரு பயனர் எதிர்பாராத தரவை அனுப்பினால் என்ன நடக்கும்?
பாதுகாப்புப் பிழைகள் அரிதாகவே சிக்கலானவை. தீய எண்ணம் கொண்டவர்கள் (bad actors) பற்றிச் சிந்திக்க நீங்கள் மறக்கும்போது அவை நிகழ்கின்றன.
நீங்கள் production-இல் கண்டறிந்த பாதுகாப்புப் பிழை எது?
Source: https://dev.to/manolito99/the-security-bug-every-nodejs-developer-ships-to-production-49e6