Pēdējā laikā sakrājušās daudz un dažādas domas un pārdomas attiecībā uz tīmekļa vietņu izstrādi. Šis ir mans pirmais bloga ieraksts, tā kā, lūgšu būt iecietīgus pret, iespējams, ne pārāk strukturizēto informācijas pasniegšanas veidu. Un tātad, atgriežoties pie pārdomām, es uzskaitīšu dažas lietas, bez dziļāka paskaidrojuma (šobrīd), un, ja esat saistīti ar vietņu izstrādi, tad šīm lietām nevajadzētu atstāt jūs vienaldzīgus:
Cik gan daudz tīmekļa vietnes ir izstrādātas par pamatu ņemot PHP skriptu valodu. Šī augstā popularitāte ir pozitīva, jo ir kā spēcīgs dzinējs tās attīstībai. Taču, kas kļūst liels un apaug ar iespējām un paplašinājumiem, neizbēgami kļūst potenciāli ievainojamāks. Šeit un šeit daži piemēri, lai labāk ilustrētu punktu par drošības līmeni risinājumiem, kas ir bāzēti uz attiecīgās valodas. Lai arī statistika nav pārāk iepriecinoša, jāatzīst, ka arī pats pamatā projektus veidoju tieši izmantojot PHP skriptu valodu. Pats gana daudz projektus esu veidojis izmantojot tieši PHP skriptu valodu. Kāpēc? Tādēļ, ka šī valoda ļauj veidot kompleksus risinājumus samazinot laiku, kas nepieciešams to izstrādei. Protams, varētu neizmantot PHP un tā vietā izmantot, piemēram, C - taču arī šeit viss nav tik rožaini, pastāv daudz plašas iespējas pieļaut bufferu pārplūdes un citas kļūmes. Kāds tad ir risinājums? Atgriežamies pie klienta vajadzību analīzes un piemērotākā tehnoloģiskā risinājuma piemeklēšanu vadoties pēc šādiem kritērijiem:
1) Realizējamā funkcionalitāte.
2) Prasības pret veiktspēju.
3) Pieejamais budžets.
4) Pieejamais laiks risinājuma realizācijai.
Un, kā rāda prakse, funckionalitāte parasti ir nepieciešama plaša, veiktspēja nav būtiskākais kritērijs, budžets, kā vienmēr, ir limitēts, laiks - visiem visu vajag jau vakar. Saliekot kopā šo standarta klienta aprakstu, diezgan loģiska ir PHP izvēle vairumā gadījumu, pat neskatoties uz potenciāli augsto riska pakāpi. Protams, daļu riskus var izslēgt, kaut vai elementāri ievērojot OWASP norādes attiecībā uz standarta kļūmēm.
Noteikti, strukturizēšu domas precīzāk, šobrīd, 2:11AM nav īsti vēlmes. Vēl tikai rezumējot to, ko vēlējos ar šo visu pateikt: ilgtermiņā PHP dominance var beigties visai nelāgi, jo jāpatur prātā, ka izstrādātāju veiktas korekcijas attiecībā pret PHP skriptu valodu, vēl nenozīmē, ka šie labojumi uzreiz nokļūst uz visiem hotinga serveriem pasaulē. Ne tuvu. Tas nu tad paver lieliskas iespējas nelāgajiem cilvēkiem izdarīt nelāgās lietas. Uzmanīgi izlasiet OWASP rekomendācijas, ja nodarbojieties ar tīmekļa vietņu izstrādi. Un pat ja nē, vienalga izlasiet.
Cik gan daudz tīmekļa vietnes ir izstrādātas par pamatu ņemot PHP skriptu valodu. Šī augstā popularitāte ir pozitīva, jo ir kā spēcīgs dzinējs tās attīstībai. Taču, kas kļūst liels un apaug ar iespējām un paplašinājumiem, neizbēgami kļūst potenciāli ievainojamāks. Šeit un šeit daži piemēri, lai labāk ilustrētu punktu par drošības līmeni risinājumiem, kas ir bāzēti uz attiecīgās valodas. Lai arī statistika nav pārāk iepriecinoša, jāatzīst, ka arī pats pamatā projektus veidoju tieši izmantojot PHP skriptu valodu. Pats gana daudz projektus esu veidojis izmantojot tieši PHP skriptu valodu. Kāpēc? Tādēļ, ka šī valoda ļauj veidot kompleksus risinājumus samazinot laiku, kas nepieciešams to izstrādei. Protams, varētu neizmantot PHP un tā vietā izmantot, piemēram, C - taču arī šeit viss nav tik rožaini, pastāv daudz plašas iespējas pieļaut bufferu pārplūdes un citas kļūmes. Kāds tad ir risinājums? Atgriežamies pie klienta vajadzību analīzes un piemērotākā tehnoloģiskā risinājuma piemeklēšanu vadoties pēc šādiem kritērijiem:
1) Realizējamā funkcionalitāte.
2) Prasības pret veiktspēju.
3) Pieejamais budžets.
4) Pieejamais laiks risinājuma realizācijai.
Un, kā rāda prakse, funckionalitāte parasti ir nepieciešama plaša, veiktspēja nav būtiskākais kritērijs, budžets, kā vienmēr, ir limitēts, laiks - visiem visu vajag jau vakar. Saliekot kopā šo standarta klienta aprakstu, diezgan loģiska ir PHP izvēle vairumā gadījumu, pat neskatoties uz potenciāli augsto riska pakāpi. Protams, daļu riskus var izslēgt, kaut vai elementāri ievērojot OWASP norādes attiecībā uz standarta kļūmēm.
Noteikti, strukturizēšu domas precīzāk, šobrīd, 2:11AM nav īsti vēlmes. Vēl tikai rezumējot to, ko vēlējos ar šo visu pateikt: ilgtermiņā PHP dominance var beigties visai nelāgi, jo jāpatur prātā, ka izstrādātāju veiktas korekcijas attiecībā pret PHP skriptu valodu, vēl nenozīmē, ka šie labojumi uzreiz nokļūst uz visiem hotinga serveriem pasaulē. Ne tuvu. Tas nu tad paver lieliskas iespējas nelāgajiem cilvēkiem izdarīt nelāgās lietas. Uzmanīgi izlasiet OWASP rekomendācijas, ja nodarbojieties ar tīmekļa vietņu izstrādi. Un pat ja nē, vienalga izlasiet.
Komentāri
Ierakstīt komentāru