Jump to content
php.lv forumi

Pēdiņas ierakstās atubāzē


retail666

Recommended Posts

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. ;)

Link to comment
Share on other sites

  • Replies 34
  • Created
  • Last Reply

Top Posters In This Topic

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?)

Link to comment
Share on other sites

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 by Mr.Key
Link to comment
Share on other sites

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 by F3llony
Link to comment
Share on other sites

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".

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by Mr.Key
Link to comment
Share on other sites

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ā?

Link to comment
Share on other sites

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. :>

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...