Mr.Key Posted October 9, 2012 Report Share Posted October 9, 2012 Mr.Key, skatoties kādas pēdiņas. Piemēram, html tekstā, virsrakstos neizmantosi ', ", <, > un kas tur vēl. Teksti ar XSS apdraud lietotāja kontu. Apdraud, ja viņus izvada HTML lapā un lapu attēlo pārlūkā. Datubāzes TEXT laukā neko neapdraud. ;) Quote Link to comment Share on other sites More sharing options...
F3llony Posted October 9, 2012 Report Share Posted October 9, 2012 Mr.Key, skatoties kādas pēdiņas. Piemēram, html tekstā, virsrakstos neizmantosi ', ", <, > un kas tur vēl. Teksti ar XSS apdraud lietotāja kontu. DBMS GIGO - Normālā gadījumā XSS ir iespējams tikai brīvā lietotāja ievadē. 80+ procentos gadījumu lietotāja ievade ir nebrīva - vārds, uzvārds, linki, teksta dati, skaitļi. Šādos datos speciālie simboli nav jākodē - tie ir jāstripo un lietotājam jādod ar belzni tieši pierē. Apdraud, ja viņus izvada HTML lapā un lapu attēlo pārlūkā. Datubāzes TEXT laukā neko neapdraud. ;) Skat. komentāru augstāk. (Tev savas db nemaz nav žēl - miskasti glabāt?) Quote Link to comment Share on other sites More sharing options...
Mr.Key Posted October 9, 2012 Report Share Posted October 9, 2012 (edited) Viss jau atkarīgs no projekta, es parasti pieturos pie principa, ka ja vienums satur sliktu daļu, tad labāk dzēst uzreiz visu vienumu, ko mazu lapu gadījumā veic admins, redzot, ka ieraksts ir kaut kādi ķeburi (redz, jo viss tiek attiecīgi eskeipots). Lielu lapu vai liela slinkuma gadījumā, piekrītu, svītrošana ir labs variants. Automatizēta filtrēšana varētu būt nepieciešama pie liela datu apjoma un pie nosacījuma, ka lietotāji var vadīt HTML (HTML editori). Ja lietotāji nevar vadīt HTML, viņiem tiek izvadīts ar htmlspecialchars() vai, precīzāk sakot, ar templeita escape() f-ju un XSS neizpildās, jo tas tiek attēlots kā teksts. Īsi sakot, ja lapas funkcionalitāte neparedz bagātinātu lietotāju veidotā satura attēlošanu, vnk escape un viss. Šajā gadījumā, glabāt jau datubāzē html escaped tekstu ir sava veida optimizācija. Edited October 9, 2012 by Mr.Key Quote Link to comment Share on other sites More sharing options...
F3llony Posted October 10, 2012 Report Share Posted October 10, 2012 (edited) Viss jau atkarīgs no projekta, es parasti pieturos pie principa, ka ja vienums satur sliktu daļu, tad labāk dzēst uzreiz visu vienumu, ko mazu lapu gadījumā veic admins, redzot, ka ieraksts ir kaut kādi ķeburi (redz, jo viss tiek attiecīgi eskeipots). Lielu lapu vai liela slinkuma gadījumā, piekrītu, svītrošana ir labs variants. Automatizēta filtrēšana varētu būt nepieciešama pie liela datu apjoma un pie nosacījuma, ka lietotāji var vadīt HTML (HTML editori). Ja lietotāji nevar vadīt HTML, viņiem tiek izvadīts ar htmlspecialchars() vai, precīzāk sakot, ar templeita escape() f-ju un XSS neizpildās, jo tas tiek attēlots kā teksts. Īsi sakot, ja lapas funkcionalitāte neparedz bagātinātu lietotāju veidotā satura attēlošanu, vnk escape un viss. Šajā gadījumā, glabāt jau datubāzē html escaped tekstu ir sava veida optimizācija. Tātad Tu ļauj lietotājam datubāzē vadīt visādus mēslus un pēc tam filtrē to izvadē? Ģeniāli. Līdz brīdim, kad kāds cits vai tu pats aizmirsīsi to izdarīt. ---> GIGO Nevajag tev programmēt... Edited October 10, 2012 by F3llony Quote Link to comment Share on other sites More sharing options...
marrtins Posted October 10, 2012 Report Share Posted October 10, 2012 Nu nu. Tu pēdējā laikā paliec ļoti strikts un nefleksiabls ;) Piemēram, es vienā projektā daru precīzi tāpat. Ir oriģinālais netīrais teksts, kas "nokompilējas" - izfiltrējas, nofomatējas un citādi apstrādājas - un saglabājas atsevišķā laukā. Vajadzības gadījumā (mainās formatēšanas noteikumi, bugs un tamldz.) dati vienkārši tiek "pārkompilēti". Quote Link to comment Share on other sites More sharing options...
F3llony Posted October 10, 2012 Report Share Posted October 10, 2012 Mārtiņ, tā nav gluži standarta situācija, vai ne? :) Es šeit runāju par standarta situācijām. Protams, dažreiz nepieciešams glabāt raw, piemēram, ja zināms, ka vēlāk mainīsies formatējuma un apstrādes loģika. Taču parasti tā nekad nebūs. Piemēram, kā gan tu varētu mainīt apstrādes loģiku tik bieži sastopamajiem laukiem, kā vārds, uzvārds, pilsēta kurā dzīvo, mīļākais ēdiens utml. informācija? Vai privātās ziņas tēma? Utt. Un lielā vairumā gadījumu, pat ja vēlāk formatējums mainās - tas vienalga tiek ģenerēts pie ievades, ne pie katras izvades, kas ir gana neefektīvi, un lai saglabātu oriģinālo satura izskatu pat tad, ja kāda brīdī sistēmā tiktu mainīta apstrādes loģika. Quote Link to comment Share on other sites More sharing options...
spainis Posted October 10, 2012 Report Share Posted October 10, 2012 kuri simboli tad ir maģiski atļautie? A-Za-z? Quote Link to comment Share on other sites More sharing options...
F3llony Posted October 10, 2012 Report Share Posted October 10, 2012 Atkarīgs no ievades lauka. Vārdam, uzvārdam "A-ž" (unicode), "-","\s" piemēram. Ja laukā nav paredzēta HTML ievade - HTML simboliem tur nav jābūt. Visam protams ir izņēmumi, bet pamatā tā tas ir. Quote Link to comment Share on other sites More sharing options...
spainis Posted October 10, 2012 Report Share Posted October 10, 2012 tas ir lokāliem projektiem, bet globāliem? un ja DB glabā eskeipotu, kas notiek, ja, piemēram, ir jāsūta plain-text'a e-pasti, tiek konvērtēts otrā virzienā? Quote Link to comment Share on other sites More sharing options...
Kemito Posted October 10, 2012 Report Share Posted October 10, 2012 Cik tie posti ir veci? Nav jēgas izmantot mysql_real_escape_string šobrīd vairs. Vainu izmanto ko elementāru, vai, ja ir nepieciešams jau drošāks veids, tad pārejam uz PDO lietošanu, nevis spītīgi turamies pie veciem standartiem. Tad ēst čipsus un dzert kolu arī ir veselīgi, right? Quote Link to comment Share on other sites More sharing options...
F3llony Posted October 10, 2012 Report Share Posted October 10, 2012 Kādiem lokāliem projektiem? Par ko tu tur runā, ko? Es saku, ka draza ir jāaizvāc pirms ko ievietot datubāzē. Tad sūtot epastu "plaintekstā" nekas nekur nebūs jākonvertē. Quote Link to comment Share on other sites More sharing options...
Mr.Key Posted October 10, 2012 Report Share Posted October 10, 2012 Nevajag tev programmēt... Mazliet par daudz pašpārliecināts esi, kaut gan neizskatās, ka proti vairāk par standarta web projektiem un klišejiskām pieejām, kuras pat ne vienmēr ir tās pareizās. Quote Link to comment Share on other sites More sharing options...
Mr.Key Posted October 10, 2012 Report Share Posted October 10, 2012 (edited) Kādiem lokāliem projektiem? Par ko tu tur runā, ko? Es saku, ka draza ir jāaizvāc pirms ko ievietot datubāzē. Tad sūtot epastu "plaintekstā" nekas nekur nebūs jākonvertē. Tas, kādi dati jāglabā datubāzē un kas notiek ar tiem pirms saglabāšanas (precīzāk - apstrādājot tos pēc lietotāja ievades saņemšanas) vai kā tie tiek apstrādāti vēlāk, nosaka daudzi faktori. Pašlaik tu sevi reklamē tā, ka vienīgais, ko saproti, ir datubāze kā mājaslapu satura "storage" tipiskos gadījumos viena veida projektos, ar kādiem nu tev sanāk darboties. Tātad Tu ļauj lietotājam datubāzē vadīt visādus mēslus un pēc tam filtrē to izvadē? Ģeniāli. Līdz brīdim, kad kāds cits vai tu pats aizmirsīsi to izdarīt. ---> GIGO 1. Lietotājs datubāzē neko neievada. 2. Nekas netiek filtrēts 3. Lasi uzmanīgāk, neizdari pieņēmumus un tad nebūs muļķīgu secinājumu. Par šo varēsim parunāt kādā dev pasākumā. Saprotu, ka tev ir viedoklis. Edited October 10, 2012 by Mr.Key Quote Link to comment Share on other sites More sharing options...
spainis Posted October 10, 2012 Report Share Posted October 10, 2012 Kādiem lokāliem projektiem? Par ko tu tur runā, ko? Es saku, ka draza ir jāaizvāc pirms ko ievietot datubāzē. Tad sūtot epastu "plaintekstā" nekas nekur nebūs jākonvertē. kāds ir tad tavs regex, lai atļautu rakstīt arābu vai manderīnu valodā? Quote Link to comment Share on other sites More sharing options...
v3rb0 Posted October 10, 2012 Report Share Posted October 10, 2012 es pie tiem, kas saka ka nekas ievadītajos datos nav jākoriģē, bet gan saglabājot jāpieņem ka vienmēr var būt sliktie simboli un jāsaglabā ar visiem sliktajiem simboliem (mazums kādam tiešām ielikuši vārdu '--drop table'), parādot atkal jāpieņem ka visur var būt būt sliktie simboli (nekad nevar zināt, ka vienmēr datus db ievadīs tikai ar tavu scriptu, kurš tur visu kārtīgi izstripojis/aizvietojis un sagatavojis parādīšanai). un vispār, viss ir slikti. :> Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.