Pereiti prie turinio

Kas šiandien yra saugu pateikti klientui?


Rekomenduojami pranešimai

Sveiki,

 

Domina svetainės kūrimas naudojant papraščiausią turinio valdymą:

 

  1. Administratoriaus puslapis
  2. Duomenų įregistravimas MYSQL bazėje per admin puslapį.
  3. MYSQL duomenų atvaizdavimas puslapyje

 

Kalbant apie saugumą į ką labiausiai reikėtų atkreipti dėmesį kuriant kiekvieną iš šių punktų? Noriu išgirsti nuomonių apie PDO, mysql_query ir t.t

Redagavo svedas
Nuoroda į pranešimą
Dalintis kituose puslapiuose

Naudok PDO vietoj mysql_*, nes mysql_* nebėra vystoma ir ateityje liks nepalaikoma, taip pat su PDO yra lengviau apsisaugoti nuo SQL injekcijų (žinoma, jeigu darysi protingai ir nepaliksi skylių) jeigu bindinsi parametrus, o daugiau apie PDO ir mysql_* čia: http://php.net/manual/en/mysqlinfo.api.choosing.php

Kitas aspektas, tai taip pat reiktų filtruoti duomenis įregistruojant duomenis į duomenų bazę: ieškot "<?php", "<script>" ir juos pašalint, arba tiesiog simbolius "<", ">" pakeist HTML ASCII kodais (tada neveiks <b>, ir kiti HTML tag'ai, bet ir tam yra sprendimas). Atrodo, kam tokius dalykus reikia daryti, jeigu tik klientas redaguos puslapius, tačiau gali atsitikti variantas, kai kažkokiu būdu nutekėjus tinklapio turinio valdymo sistemos slaptažodžiui, gali pasinaudoti kitas žmogus piktais tikslais, ir įdėti kenksmingą kodą.

Nuoroda į pranešimą
Dalintis kituose puslapiuose

Kitas aspektas, tai taip pat reiktų filtruoti duomenis įregistruojant duomenis į duomenų bazę: ieškot "<?php", "<script>" ir juos pašalint, arba tiesiog simbolius "<", ">" pakeist HTML ASCII kodais (tada neveiks <b>, ir kiti HTML tag'ai, bet ir tam yra sprendimas). Atrodo, kam tokius dalykus reikia daryti, jeigu tik klientas redaguos puslapius, tačiau gali atsitikti variantas, kai kažkokiu būdu nutekėjus tinklapio turinio valdymo sistemos slaptažodžiui, gali pasinaudoti kitas žmogus piktais tikslais, ir įdėti kenksmingą kodą.

Ne. Reikia ne šalinti pavojingus simbolius (nes tą dažnai galima apeiti),o escapinti atitinkamai (HTML tagų atveju).

 

PHP kodo apskritai, jei nenaudosi eval/include/etc. ant userio duotų doumenų, tai niekaip neįvkydysi (echo "<?php" nėra pavojinga, nes tiesiog išvedinėja tekstą į HTML, o ne į PHP interpretatorių).

 

PDO yra saugesnė už ext/mysql su ta sąlyga, kad visad naudojiesi prepared statements. PDO pats niekaip stebuklingai nesaugo ir jei sukišinėsi vartotojo inputą tiesiog, vis tiek būsi pažeidžiamas.

Tas pats galioja bet kuriai kitai sintaksei, kur kiši userio duomenis. Pvz. shell scriptams irgi reikia escapinti duomenis atitinkamomis funkcijomis (escapeshellarg, o gal escapeshellcmd? Turbūt pirmoji). Nes lygiai taip pat į

# shell komanda, ne PHP statementas
echo "$vardas"

Galima įkišti

"; rm -rf ~/ #

Redagavo Silke
Nuoroda į pranešimą
Dalintis kituose puslapiuose

O kam taip žaistis? Manai tai bus naudinga? Jeigu jau pasiekė failus, tai manau ir database pasieks.

Ką reiškia žaistis? Tame ir esmė - it takes like 10 seconds, o šiokį tokį saugumo prieaugį gauni.

 

Tame ir esmė antrąkart - jei pasiekė failą, su encryptintu config failu nieko žmogelis neišpeš. Kažkas pamiršo atsiloginti ir valytoja į USB nukopijavo visus failus? Whatever. Staiga kažkokia spraga web servery ir maloniai servina config failus? Whatever. Netyčia į public repo sucommitinai config failą? Whatever.

 

Nesuprantu. Lengva kaip du pirštus apmyžti, saugumo prideda. Nedaug, but it's still security++. Why wouldn't you do it? Why?

Redagavo Deviltry
Nuoroda į pranešimą
Dalintis kituose puslapiuose

Vis tiek įdomu, kaip su raktu. Jei aplikacija galės jį programiškai pasiekti, galės ir įsilaužėlis.

Dauguma atvejų - taip. Tai ką? Dabar ir duomenų bazių neapsaugome slaptažodžiais - juk tik iš vidinio tinklo pasiekiama? HTTPS nenaudokime - vis tiek gali išlįsti Hearthbleed #2 ir HTTPS patekins daug svarbios informacijos? Durų nerakinkime - vis tiek su kūju spyną išmuš?

 

Gana juokinti žmones, config failus encryptinti reikia - super simple 101 basic security stuff. Come on. Srsly. Come on.

Redagavo Deviltry
Nuoroda į pranešimą
Dalintis kituose puslapiuose

Dauguma atvejų - taip. Tai ką? Dabar ir duomenų bazių neapsaugome slaptažodžiais - juk tik iš vidinio tinklo pasiekiama? HTTPS nenaudokime - vis tiek gali išlįsti Hearthbleed #2 ir HTTPS patekins daug svarbios informacijos? Durų nerakinkime - vis tiek su kūju spyną išmuš?

 

Gana juokinti žmones, config failus encryptinti reikia - super simple 101 basic security stuff. Come on. Srsly. Come on.

 

Nelabai suprantu ar tu čia erelį vaidinti bandai ar šiaip trolis išlindęs...

 

Kokia logika, jeigu tame pačiame framework'e yra sakykim du failai - config.php ir database.php. Į vieną iš jų suvedi visus savo encryptinimo raktus ir t.t., o kitame prisijungimus ir viskas. Veikia be problemų. Dabar pagal tavo logiką, tam, kad naudoti prisijungimą prie database kiekvieną kartą turėsiu dar ir decrypt logoritmą paleisti, nes mano duomenys "saugūs"? Ar kaip?

 

 

ps. Tavo pvz su valytoja:

Ateina valytoja, nusikopina failus - sveikinu. Pamato config'e, kad dabatase užkoduoti. What's the problem? ( juk ne ji kažką darys, o tas kas nors kiek nuraukia, nemanai? ) Ateinu į tavo failus ir ieškau salt'o ( vistiek kažkur saugosi ar rimtai iš atminties vedžiosi ( o kaip tada useriui? ) ) ir jį radau. Dabar kokia problema man atsekti su kuo to atkoduoji/ užkoduoji? Na ok. Sakykim kažką gudriau padaręs. Kitas pavyzdys - susirandu tavo database prisijungimą ir grynai jungiantis ( juk vistiek atkoduosi :D ) išvedu visus prisijungimus. Problem? Where's your safety now?

 

O dar realiau žiūrint jeigu reikia saugumo pasidaryk serverinę programą ir su ja bendrauk per socket. Tada išvis į database niekas neįsilauš ir problemu nebus jokių.

Nuoroda į pranešimą
Dalintis kituose puslapiuose

Dauguma atvejų - taip. Tai ką? Dabar ir duomenų bazių neapsaugome slaptažodžiais - juk tik iš vidinio tinklo pasiekiama? HTTPS nenaudokime - vis tiek gali išlįsti Hearthbleed #2 ir HTTPS patekins daug svarbios informacijos? Durų nerakinkime - vis tiek su kūju spyną išmuš?

 

Gana juokinti žmones, config failus encryptinti reikia - super simple 101 basic security stuff. Come on. Srsly. Come on.

Daug kalbi ir nieko nepasiūlai. Sakai, kad encryptionas yra super easy, bet esmė, kad negali pasiūlyti efektyvaus modelio, nes yra ta problema, kurią jau keliskart minėjau. O encryptinus ir šalia laikant raktą tai encryptioną įveikti reiks tiek pat laiko, kiek kokį nors ROT13...

 

Palyginimai labai negeri. DB apsaugoti slaptažodžiais reikia, nes, pirmiausiai, ginamės nuo kitų vartotojų tame pačiame serveryje (ar tai būtų kiti sharedo/cloudo vartotojai, ar webshellas su `www-data`).

 

HTTPS pats yra saugus, o Heartbleed yra vienos TLS implementacijos side-effectas. Bugas kuris net neatsirado dėl HTTPS protokolo spragos, o pačių susikurto papildymo jam (ir dar visiškai bukos klaidos su atminties valdymu).

 

Žodžiu, primygtinai siūlai šifravimą, kuris neefektyvus, nes raktas yra pasiekiamas įsilaužėliui. Tai tas pats, kaip uždėti tavo minėtą spyną, o raktą padėti šalia jos.

 

Iš esmės šiaudinę baidyklę / slidžią nuokalnę darai su mano argumentais. Aš nesakau, kad reikia nesisaugoti akivaizdžiai tinkamais ir efektyviais būdais. Bet, dar kart, tokio šifravimo, kaip siūlai, dar nežinai, kaip padaryti efektyvaus. Galiausiai, galėdamas redaguoti failus, įsilaužėlis tiesiog įkiš naujas užklausas į jau esamos aplikacijos kodą (kuri kažkaip stebuklingai bus saugiai iššifravusi duomenis).

Redagavo Silke
Nuoroda į pranešimą
Dalintis kituose puslapiuose

aspnet_regiis -pe "connectionStrings" -app "/MyApplication"

Viena komanda, ++security. Yeah I'm a troll and you all are good software developers. Tikėk tuom.

Ir turbūt net pats nežinai, kaip šifruojama. Stebuklingoji komanda, kuri bus prieinama ir įsilaužėliui. Sveikinu. Microlol == security.

Nuoroda į pranešimą
Dalintis kituose puslapiuose

Prisijunkite prie diskusijos

Jūs galite rašyti dabar, o registruotis vėliau. Jeigu turite paskyrą, prisijunkite dabar, kad rašytumėte iš savo paskyros.

Svečias
Parašykite atsakymą...

×   Įdėta kaip raiškusis tekstas.   Atkurti formatavimą

  Only 75 emoji are allowed.

×   Nuorodos turinys įdėtas automatiškai.   Rodyti kaip įprastą nuorodą

×   Jūsų anksčiau įrašytas turinys buvo atkurtas.   Išvalyti redaktorių

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

Įkraunama...
  • Dabar naršo   0 narių

    Nei vienas registruotas narys šiuo metu nežiūri šio puslapio.

  • Prisijunk prie bendruomenės dabar!

    Uždarbis.lt nariai domisi verslo, IT ir asmeninio tobulėjimo temomis, kartu sprendžia problemas, dalinasi žiniomis ir idėjomis, sutinka būsimus verslo partnerius ir dalyvauja gyvuose susitikimuose.

    Užsiregistruok dabar ir galėsi:

    ✔️ Dalyvauti diskusijose;

    ✔️ Kurti naujas temas;

    ✔️ Rašyti atsakymus;

    ✔️ Vertinti kitų žmonių pranešimus;

    ✔️ Susisiekti su bet kuriuo nariu asmeniškai;

    ✔️ Naudotis tamsia dizaino versija;

    ir dar daugiau.

    Registracija trunka ~30 sek. ir yra visiškai nemokamai.

  • Karštos temos

×
×
  • Sukurti naują...