Jump to content
php.lv forumi

PHP un templeitu sistēmas


briedis

Recommended Posts

Inputa html eskeipings? Jūs jokojat? 

Nav laika lasīt to blobu, bet es pieņemu, ka autors ir nejēga. Tas, nekas, ka kaut kur core devs.

 

Kas te ieminējās par "XSSīgu datu nepielaišanu līdz templeitam"... lūdzu, izdzeriet indi un aizejiet nomirt. Jebšu jums šķiet, ka "<script>window.alert('trololo')</script>" ir slikts username, kā arī šis posts nemaz nedrīkstētu saturēt šo tekstu? :)

Jā, tas ir slikts username, un šis posts drīkst saturēt šo tekstu. Now what?

 

Pat nefiltrējot pie inputa, username "<script>window.alert('trololo')</script>" būtu jāparādās šādi:

 

Sveiks, <script>window.alert('trololo')</script>! | Profils | Iziet

 

Vai formā:

 

Vārds: [<script>window.alert('trololo')</script>! ]

 

Ja parādās alerts vai input lauku nograuj pēdiņas ievadītajā saturā... Bērnudārzos veido sistēmas, kur nospied divas reizes "Saglabāt" un teksta vērtība "SIA 'M&K'" pārvērtusies par kaut ko [sIA ] &amp;K'. Lieki piebilst, kas notiek ar tādu attieksmi programmētā risinājumā, nedaudz pieaugot datu apjomam.

SIA un M&K ir 2 fieldi, btw. Nu tā, runājot par bērnudārzā veidotām sistēmām.

 

Un tagad, par general ņaudienu par "escape-on-input", pieņemsim sekojošu scenāriju:

  1. Eksistē sistēma A un B, kuru izveidoja developeris X un abas darbojas pret datasourci R (mysql for example). A domāta datu ievadei, B domāta izvadei.
  2. Es esmu ļāūņš hax0rz11 un ievadu sistēmā A <evilscript> kas izpildītos UI sistēmā B, bet...
  3. Sistēmas B autors domā, ka nav cirvis un šos datus eskeipo (vienmēr un visur kur tie tiek izvadīti, jayy, katru reizi, because feasability)
  4. Mans <evilscript> neizdodas. Taču...
  5. Atnāk developeris Y un pie datasources R piekabina frontendu C, kas šos datus eskeipot aizmirst (one time is enough).
    1. Vai atnāk developeris Z un izeksportē šos datus no R iekš kaut kāda HTML reporta. Vai PDF. Vai Excel. Es zinu, ka tas var notikt, therefore es var izjāt visu iepriekš minēto un vēl nedaudz.
  6. <evilscript> tiek izpildīts un es nežēlīgi izjāju sistēmu C, tad B un A, un tad arī pašus developerus X un Y.
  7. ... Profit

Praktisku piemēru netrūkst. Log failu rīderis ar SQL injekcijām, jo kāds lohs izdomāja, ka ir okei logus glabāt SQL un aggregators piemirsa eskeipot "User ';DROP TABLE users;' logged in 1985-01-01 LOLOLOL" utt. utjp.

 

Šeit daži bulletpointi:

  1. Whitelist, not blacklist.
  2. Garbage in - garbage out, the quality of output is determined by the quality of the input. Softs, kas labprātīgi pieņem sūdīgus datus tad arī saturēs sūdīgus datus un izvadīs sūdīgus datus.
  3. Ar puslīdz precīzu validāciju eskeipot vispār nav ko, jo validācija pieņems tikai datus, kurus tā sagaida saņemt - nevis close enough.
  4. Vārds / Uzvārds satur UTF8 "vārdiskos" simbolus un dažus special characters. Neko tur īsti neinjicēsi. Tu pieļauj savu aplikāciju piesūdot ar ko pagadās? Skat. 7. punktu.
  5. Epasts ir epasts, tam ir noteikts formāts. Neko tur diži neinjicēsi.
  6. HTML inputi? Tags whitelist. Visu pārējo HTML eskeipot/enkodēt. 
  7. Atļauj pievienot jebko, kas atgādina kodu savam output HTML? Tu esi vājš. Tava dzimta ir vāja. Jūs neizdzīvosiet ziemu.
  8. Tu esi 100% pārliecināts, ka to fieldu pareizi eskeipoji visur, kur to izvadi? TIEŠĀM?

Lieki piebilst, kas notiek ar sistēmām, kuras raksta escape-on-output'isti...

Link to comment
Share on other sites

  • Replies 111
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Es tikai nesaprotu, ko tik agresīvi un puiciski izsakies? Ja viedoklis ir vērtīgs, tas nav jāpavada ar dzērāju tipa epitetiem. Tas tā, piebilde.

Kas attiecas uz SQL piemēru un citiem piemēriem vispār, ir diezgan vienkāršs veids, kā vienkāršu risinājumu padarīt komplicētu, grūti uzturamu un pārbagātu ar kļūdām - kad sāk domāt divus soļus pa labi, pa kreisi, nevis vienkārši nodalīt katra slāņa atbildību un neuztraukties par pārējo. Kā tas ir gadījumā, kad "vai tiešām templeitos nebūs aizmirsts escape? Labāk to darīt pirms templeita, tā drošāk..." un tad ticketos pilns ar "The title in the page X appears as "Title"", utml.

Nemēģinu pārliecināt, ka tas ir nepareizi – personisks novērojums ir tāds, ka šādas samudžinātas sistēmas ir labs bizness - programmētāji pārgudri ņemas vienā laidā, raksta unescape_unescape funkcijas un workaroundus. Utml.

 

Mans viedoklis: Tas ir ļoti vienkārši - escape on output (vai veidojot SQL). Šajā gadījumā ir tikai viens bulletpoints: 1) escape on output.

Link to comment
Share on other sites

 

 

When someone does a keyword search for 'amp', they get "Jack & Jill". Why? Because you've corrupted your data.

 

http://stackoverflow.com/questions/11253532/html-xss-escape-on-input-vs-output

 

 

 

Atnāk developeris Y un pie datasources R piekabina frontendu C, kas šos datus eskeipot aizmirst (one time is enough).

 

Atnāk developeris W, uztaisa "konsoles" frontendu un domā ... wtf?!

Edited by Blitz
Link to comment
Share on other sites

Gribētu redzēt kā kāds strādātu ar datiem, kuri jau ir eskeipoti pret HTML, pret SQL, u.c. lietām - vienlaicīgi.

Skat. Nr. 3

Es tikai nesaprotu, ko tik agresīvi un puiciski izsakies? Ja viedoklis ir vērtīgs, tas nav jāpavada ar dzērāju tipa epitetiem. Tas tā, piebilde.

 

Kas attiecas uz SQL piemēru un citiem piemēriem vispār, ir diezgan vienkāršs veids, kā vienkāršu risinājumu padarīt komplicētu, grūti uzturamu un pārbagātu ar kļūdām - kad sāk domāt divus soļus pa labi, pa kreisi, nevis vienkārši nodalīt katra slāņa atbildību un neuztraukties par pārējo. Kā tas ir gadījumā, kad "vai tiešām templeitos nebūs aizmirsts escape? Labāk to darīt pirms templeita, tā drošāk..." un tad ticketos pilns ar "The title in the page X appears as "Title"", utml.

 

Nemēģinu pārliecināt, ka tas ir nepareizi – personisks novērojums ir tāds, ka šādas samudžinātas sistēmas ir labs bizness - programmētāji pārgudri ņemas vienā laidā, raksta unescape_unescape funkcijas un workaroundus. Utml.

 

Mans viedoklis: Tas ir ļoti vienkārši - escape on output (vai veidojot SQL). Šajā gadījumā ir tikai viens bulletpoints: 1) escape on output.

Jo es esmu tāds puicisks un agresīvs. Ko padarīsi. 

 

Tieši tā - šis vienkāršais veids ir nepieļaut sūdīgus datus sistēmā. Tā pat kā rakstīt sūdīgu kodu - sākumā viegli un "ērti", pēc tam...

Link to comment
Share on other sites

Videi, kurā tiek izvadīti dati pašai ir jāparūpējās par "kaitīgo" simbolu virknēm!

 

Piemēram, html aplikācijā <script> būs kaitīgs, bet kaut kādā desktop aplikācijā, tāds <script> vispār neko neizsaka.

 

Tu tak nevari paredzēt kādās vidēs tavi dati tiks izvadīti. Varbūt nākotnē uzradīsies sistēma, kurā simbolu virkne "&" palaiž atombumbu.

Šajā gadījumā sanāks, ka tu pats esi savu datubāzi uzhakojis

Link to comment
Share on other sites

Videi, kurā tiek izvadīti dati pašai ir jāparūpējās par "kaitīgo" simbolu virknēm!

 

Piemēram, html aplikācijā <script> būs kaitīgs, bet kaut kādā desktop aplikācijā, tāds <script> vispār neko neizsaka.

 

Tu tak nevari paredzēt kādās vidēs tavi dati tiks izvadīti. Varbūt nākotnē uzradīsies sistēma, kurā simbolu virkne "&" palaiž atombumbu.

Šajā gadījumā sanāks, ka tu pats esi savu datubāzi uzhakojis

Ko? Kas pie...? Labi es vispār nemaz nemēģināšu saprast tavu domu gājienu...

 

Atnāk developeris W, uztaisa "konsoles" frontendu un domā ... wtf?!

Kāpēc? 

 

 

Es nesaprotu vispār kāpēc panesies ir šāds interesants topiks. Jo vai kāds vispār var pateikt kaut vienu normālu piemēru izņemot kaut kādus komentārus un forumus + wysiwyg inputus CMSos utml, kur jebkāda HTML/JS/whatever koda-alike inputa klātbūtne ir reālistisks variants pieņemamiem datiem ievadē?

 

Visu problēmu sākuma punkts ir tas, ka sistēmas pieļauj ievadīt jebko un jebkur - skat. punktu 3. vēlreiz.

 

P.S. Lai mani nepārprastu, es nerunāju par aklu un tizlu "visa inputa barošanu htmlspecialchars" :D Apply common sense. 

Edited by F3llony
Link to comment
Share on other sites

Tāpēc ka <, >, &, " ir pilnīgi normāli dati/chari, un lai normāli viņi arī glabājas.

Un vel DB laukos ar ierobežotu garumu. šāda makslīga datu papildināšana zog tikai vietu, un pie kā tas var novest? Kavacky vairs savu kruto username nevarēs ievadīt, kaut pēc simbolu skaita to vajadzētu varēt.

Edited by Blitz
Link to comment
Share on other sites

Tāpēc ka <, >, &, " ir pilnīgi normāli dati/chari, un lai normāli viņi arī glabājas.

Un vel DB laukos ar ierobežotu garumu. šāda makslīga datu papildināšana zog tikai vietu, un pie kā tas var novest?

Pilnīgi normāli dati/chari, saki. Kādā tieši gadījumā tevis minētie ir normāli čari, piemēram, username? Vai datumā. Vai epasta adresē. Vai jebkurā citā ne-free-input lauka tipā, kādu vien vari iedomāties.

Link to comment
Share on other sites

 

 

 piemēram, username?

Kas vainas username Jack&Jil, vai <B>litz ? Vai "Blitz"? 

 

 

 

Vai datumā. Vai epasta adresē.

Tie ir specifiski formāti, attiecīgi validē. Ja eksistē reāli ierobežojumi (nevis programmeru izdomāti, jo redz kautkāda browserī kautkā specifiski attēlojas) tad pret tiem validē, no problems. Par šo nediskutēju.

Link to comment
Share on other sites

Es pareizi saprotu, Robert, ka tu iesaki escapot datus pret XSS un tad šamus glabāt iekš datubāzes, jau escapotus?

 

Nē, es iesaku vispirms validēt un datus, kas neatbilst validācijai vispār sistēmā nepieņemt. Un gadījumos, kur nav iespējas reāli validēt (man gan ir grūti tādus gadījumus pat iedomāties), eskeipot un glabāt - tieši tā. Vai sliktakajā gadījumā, glabāt tā, ka pie izvades tie ir jātransformē obligāti un savādāk tos vispār nevar izvadīt, vai arī tas ir acīmredzams, ka konkrētie dati ir "raw" un potenciāli satur bīstamus datus.

Edited by F3llony
Link to comment
Share on other sites

Tas ka plain PHP output escape by default nenotiek, bet template engine notiek un tam vairs nav jāpievērš speciāla uzmanība, izņemot vietās kur tu specili forcē templeitam rādit neeskeipotu saturu.

Nu jā, bet man, izmantojot elementāru, paštaisītu MVC paternu, tas tāpat by default ir elementāri iespējams.

 

Lai nav offtopic, man viedoklis par template.

Man personīgi patīk tīri risinājumi, kas radīti un optimizēti konkrētam uzdevumam.

Kādam citam ir ērtāk paņemt gatavu un pielāgot savām vajadzībām.

Mīnusi, ko saskatu:

- lieks kods/funkcionalitāte

- drošība (atvērtā kodā vieglāk atrast kļūdas)

- ilgāk jārisina problēmas (jo nepārzini kodu no A-Z)

- sākumā jāvelta laiks, lai vispār iepazītos un saprastu konkrētās sistēmas darbību

 

Pa lielam jau templeitu sistēma PHP patterns vien ir, kāda cilvēka vai cilvēku grupas izpildijumā.

+ ja pārzini sistēmu var ietaupīt daudz laika, jo daudz kas ir gatavs

+ kāds cits, kurš pārzin konkrēto sistēmu, var risināt problēmas

Edited by webi
Link to comment
Share on other sites

 

 

Nu jā, bet man, izmantojot elementāru, paštaisītu MVC paternu, tas tāpat by default ir elementāri iespējams.

 

Kā? <?=doescape($value);?> ? Jā tā var, pie nosacījuma ka vienmēr doescape tiks lietots un "nepiemirsīsies"

 

 

 

Man personīgi patīk tīri risinājumi, kas radīti un optimizēti konkrētam uzdevumam.

Kādam citam ir ērtāk paņemt gatavu un pielāgot savām vajadzībām.

 

Kuru template-engine esi lietojis? Kādu freimworku (izņemot pašrakstīto) esi lietojis?

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