Kysymys:
SQL-injektio - miksi pakolainaukset eivät ole enää turvallisia?
Incognito
2011-05-06 19:44:52 UTC
view on stackexchange narkive permalink

Raaka SQL

Kun kirjoitat SQL-tiedostoa - mihin tahansa, mikä todella vaatii inhimillistä panosta, on tehty paljon asioita injektion välttämiseksi.

Kaikki, jotka ovat kuulleet SQL-injektiosta tietää, että (aion käyttää PHP: tä esimerkkinä) tällaisen tekeminen ei ole turvallista:

  $ sql = "SELECT * FROM ʻusers`. WHERE ʻuserName "=" {$ _POST ["käyttäjänimi"]} ". JA" pass "=" {$ _POST ["pass"]} ";";  

taika

Sitten tietysti joku keksi ajatuksen käyttää "maagisia paeta-lainausmerkkejä" käsittelemään ohjelmasyöttöä, jota ei desinfioitu oikein ja laitettiin suoraan sql-tiedostoon huonojen käytäntöjen seurauksena. Tämä ei oikeastaan ​​ratkaissut ongelmaa SQL-injektiolla, mutta se tarkoitti sitä, että kaikki käyttäjän syötteet sekoittuivat.

Kaltoviivojen lisääminen

Jotkut ihmiset sulkivat taika-lainaukset. Sitten he jäsensivät käyttäjän syötteen ennen SQL-pistettä addlashes () -kohdassa, joka teoriassa välttää kaikki lainausmerkit ja hakkeri ei voi tehdä 'OR 1 = 1 , mutta Jopa lisälaskien dokumentaatio on itsestään sanottava, että sinun ei pitäisi käyttää lisälaskelmia, siinä sanotaan, että käytä tietokantakohtaista toimintoa, kuten mysql_real_escape_string () , mutta joidenkin sanotaan silti olevan tarpeeksi <. p>

Tietokantaan liittyvien kauttaviivojen lisääminen

Emme siis voi käyttää DBMS-erityisiä * _real_escape_string -ominaisuuksia, emme voi käyttää lisää kauttaviivoja , "maagiset lainausmerkit" -asia aiheutti paljon ongelmia, ja verkko on täynnä lyhyitä sanamuotoja, kuten:

"Omistettu hakkeri löytää keinon siirtyä läpi tarjouksestasi paeta -silmukoita, käytä vain DBAL: n valmistamia lausekkeita "- John Q mikä tahansa ohjelmoija

Okei, niin se pelotti minua tarpeeksi valmistelulausekkeiden ja DBAL: n käyttämiseen. Se ei oikeastaan ​​selittänyt mitään, mutta kuulostaa hyvältä, koska olen kuullut sen paljon.

Valmistellut lausunnot

Joten nyt käytämme SANia tai DBALia kehys tai jokin muu, joka kääri kaiken sql: n ja varmistaa, että joku ei voi suorittaa sql-injektiota.

Kysymykseni on pohjimmiltaan "miksi ei?", ei "mitä minun pitäisi käyttää?". Verkko on täynnä ihmisiä, jotka käskevät sinua käyttämään tätä tai käyttämään sitä tai mitä tahansa , mutta ei selityksiä siitä, miksi näiden asioiden piti tapahtua.

Suorat kysymykset

Kohdistetut kysymykset (muistutus, kysyn SQL: stä, PHP oli esimerkkikieli, koska SQL: n ympärillä on huono edustaja, käsitteet ovat yleismaailmallisia):

  1. Miksi emme voi paeta kaikkia käyttäjän syötteitä "maaginen"?
  2. Miksi lisäysviivat eivät olleet "tarpeeksi hyviä"?
  3. Mikä vikaa DB-spesifisten paeta-toimintojen käytössä, ja miksi se oli parempi kuin lisäleimat?
  4. Miksi valmiita lausekkeita, joissa on kehyksiä ja SAN, pidetään SQL: n kultastandardina? Miksi he ovat parempia? Miksi en voi tehdä SQL-injektiota näillä, missä kuten voisin tehdä edellä mainituilla keinoilla? Voiko ohjelmoija ei jotenkin onnistua vielä kiertämään tätä? Mitä heidän tulisi varoa?
  5. Muita huolenaiheita, joita en ole esittänyt?

Seitsemän vastused:
#1
+53
Hendrik Brummermann
2011-05-07 04:16:16 UTC
view on stackexchange narkive permalink

Miksi emme voi välttää kaikkia käyttäjän syötteitä käyttämällä "taikuutta"?

Taikaa käytettäessä ei tiedetä, mihin tiedot päätyvät. Joten maagiset lainaukset tuhoavat tietoja, ellei niitä ole kirjoitettu esteettömästi tietokantaan.

Sitä voidaan käyttää vain asiakkaalle lähetettävässä HTML-vastauksessa. Ajattele lomaketta, jota ei ole täytetty kokonaan ja joka sen vuoksi näytetään uudestaan ​​käyttäjälle. Maagisten lainausmerkkien avulla ensimmäisellä yrityksellä syötetyt tiedot poistetaan nyt SQL: stä, mikä on merkityksetöntä HTML-sivulla. Vielä pahempaa: toisella lähetyksellä tiedot poistetaan SQL: stä uudestaan.

Miksi lisälaskelmia ei ollut "tarpeeksi hyviä"?

Siinä on ongelmia monitavuisten tiedostojen kanssa merkkiä:

  '27 \ 5c 뼧 bf 5c  

Nämä ovat kaksi tavua, mutta vain yksi Unicode-merkki.

Koska addlashes ei tiedä mitään Unicodesta, se muuntaa syötteen bf 27 arvoksi bf 5c 27 . Jos Unicode-tietoinen ohjelma lukee tämän, sen katsotaan olevan 뼧 '. Boom.

Asiasta on hyvä selitys osoitteessa http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

Mikä vikaa DB-spesifisten pakotustoimintojen käytössä, ja miksi se oli parempi kuin lisäysviivoja?

Ne ovat parempia, koska ne varmistavat, että pakeneva tulkitsee tietoja samalla tavalla kuin tietokanta (katso viimeinen kysymys).

Turvallisuuden kannalta ne ovat kunnossa, jos käytät niitä jokaiseen tietokantatuloon. Mutta heillä on riski, että voit unohtaa jommankumman jostakin.

Muokkaa : Kuten getahobby lisäsi: Tai että käytät numeroille xxx_escape_strings lisäämättä lainausmerkkejä niiden ympärille SQL: ssä lauseketta ja varmistamatta, että ne ovat todellisia lukuja, suoratoistamalla tai muuntamalla tulo sopivaksi tietotyypiksi /Muokkaa

Ohjelmistokehityksen näkökulmasta ne ovat huonoja, koska ne vaikeuttavat tuen lisäämistä muille SQL-tietokantapalvelinohjelmistoille.

Miksi kehyksiä ja suojattua alkuperänimitystä sisältäviä valmisteltuja lausuntoja pidetään kultataso SQL? Miksi he ovat parempia?

SAN on enimmäkseen hyvä ohjelmistosuunnittelun vuoksi. Se helpottaa huomattavasti muiden tietokantapalvelinohjelmistojen tukemista. Siinä on objektipohjainen käyttöliittymä, joka tiivistää monia pieniä tietokantakohtaisia ​​yhteensopimattomuuksia.

Miksi en voi tehdä SQL-injektiota näillä [valmistelluilla lausekkeilla], missä kuten VOIN VOIN tehdä aiemmin mainitut välineet?

Tärkeää on valmisteltujen lauseiden " vakiokysely muuttuvilla parametreilla " -kohdasta. Tietokannan ohjain pakenee kaikki parametrit automaattisesti ilman, että kehittäjän on mietittävä sitä.

Parametroituja kyselyjä on usein helpompi lukea, että normaaleja kyselyjä, joiden parametrit ovat poistuneet syntaktisista syistä. Ympäristöstä riippuen ne voivat olla hieman nopeampia.

Aina käyttämällä valmiita lausekkeita parametreillä voidaan vahvistaa staattisten koodien analysointityökaluilla . Puuttuvaa kutsua xxx_escape_string ei havaita niin helposti ja luotettavasti.

Eikö ohjelmoija voi jotenkin onnistua kiertämään tämän vielä? Mitä heidän tulisi varoa?

"Valmistellut lausekkeet" tarkoittavat, että ne ovat vakiona . Dynaamisesti luotuilla lausekkeilla - etenkin käyttäjän syötteillä - on edelleen kaikki injektiokysymykset.

Tämä on hyvin perusteellista eikä realistista. Kielen koodausongelmat eivät vaikuta 99,9%: iin verkkosovelluksista. ~ .1% sql-injektiosta löytyy staattisen koodianalyysin avulla. Ammattilaiset käyttävät paljon parempia tekniikoita. Kokemukseni perusteella voin kertoa, että käsittelemäni asiat ovat ** paljon yleisempiä **.
Olen eri mieltä @Rook, Hendrikin vastaus on hyvin realistinen. SAN-mantra on enimmäkseen tarpeeton, koska monet verkkosovellukset on rakennettu käyttämään tiettyä tietokantaa niiden käyttöiän loppuun saakka. Siksi kehittäjä on saattanut yhtä hyvin käyttää asiaankuuluvia toimintoja kuin monimutkaistaa sovellusta käyttämään 2% laajennuksen ominaisuuksista.
On vain 4 kieliryhmää, joilla on ongelmia `addlashes (): n kanssa, gbk on yksi niistä.
@Rook - jälleen kerran turvautuvat loukkauksiin sen sijaan, että vastaat kysymyksiin. Tätä ei voida hyväksyä. Sinun on joko selvitettävä viestintätyyli ja käyttäytyminen, tai meidän on turvauduttava keskeyttämiseen. Ota tämä kohteliaaksi varoitukseksi.
Viimeisimmän kysymyksen "Eikö ohjelmoija voi jotenkin onnistua kiertämään tämän vielä?", Halusin vain linkittää [äskettäiseen SQL-injektiokysymykseen] (http://drupal.stackexchange.com/questions/133795/what-kind -of-attack-does-the-patch-for-sa-core-2014-005-drupal-7-32-prevent), jotka vaikuttivat Drupal CMS -sisältöön ohittaen SAN-suojauksen.
#2
+13
Christian
2011-05-08 12:45:57 UTC
view on stackexchange narkive permalink

[1.] Miksi emme voi paeta kaikkia käyttäjän syötteitä käyttämällä "taikuutta"?

Koska maagiset lainausmerkit ovat rikki kahdessa määrässä:

  1. Kaikki $ _ (REQUEST / GET / POST) -tiedot eivät mene tietokantaan. Ja jotta voit ymmärtää sitä, sinun on poistuttava syötteestä.
  2. He ovat addlashes -vastaava (katso huomautukseni kohdasta [2.]), joten ne eivät ole todella turvallisia.

[2.] Miksi lisäysviivoja ei ollut "tarpeeksi hyviä"?

On monia tapoja päästä ulos addlashes -rajoituksesta, joten se on perustavanlaatuisesti virheellinen, mutta yrität sitä kuitenkin käyttää.

[3.] Mikä väärin DB-spesifisen pakotuksen käytössä toimintoja, ja miksi se oli parempi kuin lisäysviivoja?

Mikään ei oikeastaan. Se on yksinkertaisesti mantra siitä, miksi SAN / valmistetut ovat "parempia". Ne ovat paljon parempia kuin addlashes , koska ne huolehtivat monista tekijöistä, mukaan lukien koodaus. Tässä on pieni salaisuus; SAN käyttää niitä sisäisesti, mutta ei lisäsivuja...

[4.] Miksi kehyksiä ja suojattua alkuperänimitystä sisältäviä valmisteltuja lausuntoja pidetään kultaisena SQL? Miksi he ovat parempia? Miksi en voi tehdä SQL-injektiota näillä, missä kuten voisin tehdä edellä mainituilla keinoilla?

He eivät ole kultastandardi , he eivät ole turvallisempia kuin tietokantakohtaiset toiminnot, ja voit myös tehdä SQL-injektoinnin myös näillä. Ja ei, et voi tehdä SQL-injektiota oikein puhdistetulla syötteellä.

Kuten kaikilla siellä olevilla tekniikoilla, kehittäjillä on taipumus kehittää uskonnollisia (fanaattisia?) Taipumuksia mihin tahansa "uuteen". Siksi saat kokeneet Zend-sertifioidut insinöörit (TM) neuvomaan -ei pakottaa sinua siirtymään valmiisiin lausuntoihin.

Todellisuus on kuitenkin se, että kaikki riippuu siitä, että tiedät mitä olet tekemässä. Jos lataat artikkelia sen numeerisella tunnuksella, et tarvitse mitään pakenemista, vielä vähemmän SAN. Sinun tarvitsee vain varmistaa, että tunnus on todellakin kokonaisluku.

Realistisemmasta näkökulmasta yleisin sääntö ei ole käyttää SAN / valmistettuja lauseita, vaan käyttää oikeita toimintoja, toisin sanoen täytyy käyttää mysql_real_escape_string () -kohtaa -lisälasun () tai mysql_escape_string().

[5.] Eikö ohjelmoija voi jotenkin onnistua kiertämään tämän vielä? Mitä heidän tulisi varoa?

Tietysti! Mutta se ei ole "mistä varoa", vaan "tietää mitä olet tekemässä".

Näet, eval ($ _ GET ['code']) * on täysin laillinen, kun sitä käytetään oikeassa paikassa (kuten paikallinen PHP Test Runner).

Jos käytät ORM: ää ehdollisen kyselyn suorittamiseen, syötät koodia suoraan, joten siinä voi olla mahdollisuus saada SQL-injektio, jos et tee sitä oikein (riippuu kyseessä olevasta ORM: stä). (Hypoteettinen) Esimerkki:

  // update () asettaa sarakkeen arvon, jolla on ehto ////. - pakeneminen on tässä automaattista // | .-- hypoteettinen SQL-injektio // v vDb () - >update ('nimi', $ _ GET ['uusi nimi']) - >where ('id ='. $ _ GET ['id']);  

(* Voin vain kuvitella lukemattomien ammattilaisten paukuttavan päätä tämän yli)

+1. varsinkin API-rajapintojen haittojen osoittamiseksi, jotka sekoittavat parametrisoituja kyselyitä dynaamisiin osiin.
Hyödyllinen tekniikka verkkopyyntöjen tai koodatun datan tallentamiseksi on koodata se base64: een ja tallentaa se merkkijonona.Se ei estä SQL-injektiota tai huonoja tietoja, mutta ainakin varmistaa, että mitään syötettyä ei käytetä sellaisenaan.
#3
+9
rook
2011-05-08 01:25:29 UTC
view on stackexchange narkive permalink

Päivän lopussa syötteistä on vältettävä, jotta SQL-injektiokyselysi voidaan suojata. Parametroidut kyselykirjastot, kuten PDO ja ADODB, käyttävät pakenemista , kaikki, mitä he tekevät, ovat valvoa tätä käytäntöä implisiittisesti turvallisella tavalla. Konstrastilla magic_quotes_gpc ei EI tämä on pohjimmiltaan puutteellinen lähestymistapa ongelmaan.

1) Pakeneminen voi olla ongelmallista, jos et ymmärrä mitä teet. Tämän tyyppinen ongelma on edelleen hyödynnettävissä, jos magic_quotes_gpc on käytössä.

  mysql_query ("valitse * käyttäjistä, joissa id =". Lisää välähdyksiä ($ _ GET [id]));  

PoC Exploit: http: //localhost/vuln.php? id = sleep (30)

korjaustiedosto:

  mysql_query ("valitse * käyttäjistä, joissa id = '". lisää viivoja ($ _ GET [id]). "" ");  

Oppitunti: Sinun ei tarvitse lainausmerkkejä käyttääksesi SQL-injektointia.

2) Sanotaan, että pakenet vain lainausmerkkejä:

  mysql_query ("valitse * käyttäjistä, joissa name = '". htmlspecialchars ($ _ GET [nimi], ENT_QUOTES). "' ja id =" ". htmlspecialchars ($ _ GET [id], ENT_QUOTES)." "");  koodi> 

PoC Exploit: http: //localhost/vuln.php? name = \ &id = + tai + sleep (30) / *

Patch:

  mysql_query ("valitse * käyttäjistä, joissa name = '". lisää laskuviivoja ($ _ GET [nimi]). "' ja id = '". lisää laskuja ($ _GET [id]). "'");  

Oppitunti : taaksepäin viistot ovat yhtä vaarallisia lainausmerkeinä.

3) Entä kielikoodaus?

  mysql_query ("SET CHARACTER SET 'gbk'"); mysql_query ("select * from user where name = '". addlasheshes ($ _ GET [name]). "" ");  

PoC Exploit: http: //localhost/vuln.php? name =% bf% 27 = sleep (30) / *

Korjaus: vahva>

  mysql_query ("SET CHARACTER SET 'gbk'"); mysql_query ("select * from user where name = '". mysql_real_escape_string ($ _ GET [name]). "" ") ;  

Päätelmä:

Pakoa tarvitaan ehdottomasti estämään sql-injektio sovelluksessa. PHP: ssä PDO ja ADOB ovat hienoja parametrisoituja kyselykirjastoja, jotka pakottavat käyttäjän syötteen välttämisen. Ongelmana on, että monet ohjelmoijat eivät ymmärrä pakenemista. Kirjaston saaminen tämän turvallisen käytännön toimeenpanemiseksi on paras puolustustapa, koska sinun ei tarvitse ymmärtää pakenevia sääntöjä.

"Escaping on ehdottoman välttämätöntä estämään sql-injektio sovelluksessa", tämä on yksinkertaisesti väärin. Paljon vähemmän virhealtista lähestymistapaa kuin pakenemisen käyttäminen on käyttää parametrisoituja kyselyitä, joissa on vakio kyselyosa ja kaikki parametreissa olevat epäluotettavat tiedot. Koska tiedot eivät koskaan ole osa SQL-kyselymerkkijonoa, ei pakotusta tarvita ja tietokanta tekee vain oikein. /// Älä ehdottaa lisälasien käyttöä, koska PHP-sovellus voi olla haavoittuva merkkisarjahyökkäykselle jopa asettamatta selaussarjaa nimenomaisesti esimerkiksi MySQL-oletusasetusten vuoksi.
Esimerkiksi mysqli-ohjain: Funktio [mysqlnd_stmt_execute_store_params] (http://codesearch.google.com/codesearch/p?hl=de#ceArhxvuL0U/Oem/php/ext/mysqlnd/mysqlnd_ps_codec.c&q=mysqlnd_st_st 1 & ct = rc) lähettää parametreja palvelimelle binaaritiedona kyselymerkkijonon ulkopuolella.
@Hendrik Brummermann Mitä ylätason parametrisoitua kyselytoimintoa (http://php.net/manual/en/book.mysql.php) tämä toiminto tukee? Luulen, että olet väärässä tämän koodin toimivuudesta. Tiedän, että on väärin sanoa "paeta on huono ja että sinun tulisi käyttää sen sijaan SAN".
Liitetyt korkean tason kyselytoiminnot, jotka lopulta kutsuvat kyseistä sisäistä ohjaintoimintoa, ovat [valmistele] (http://www.php.net/manual/en/mysqli.prepare.php), [bind_param] (http: // www.php.net/manual/fi/mysqli-stmt.bind-param.php) ja [suorita] (http://www.php.net/manual/en/mysqli-stmt.execute.php). Käytän itse useimmiten pakenevaa tapaa, mutta parametrisoitujen kyselyjen käyttö on kelvollinen vaihtoehto. Ja vaikka on olemassa joitain kehyksiä, jotka korvaavat parametrit SQL-käskyyn (asianmukaisella poistumisella), tietokantatoiminnot lähettävät ne kyselyn vieressä.
@Hendrik Brummermann Olen hyvin skeptinen tässä. Pääasiassa [mysqli-koodi] (http://codesearch.google.com/codesearch/p?hl=de#ceArhxvuL0U/Oem/php/ext/mysqli/mysqli.c&q=mysqlnd_stmt_execute_store_params&d=3) ei edes [soita] tämä toiminto] (http://codesearch.google.com/codesearch?q=mysqlnd_stmt_execute_store_params&exact_package=http%3A%2F%2Fsvn.osgeo.org%2Fmapguide%2Ftrunk%2FMgDev&hl=de)
"Kirjaston omistaminen tämän turvallisen käytännön noudattamiseksi on paras puolustusmenetelmä, koska sinun ei tarvitse ymmärtää pakenevia sääntöjä" - Ja siksi, ystäväni, epäonnistumme turvallisuudessa. Totuus on, että ohjelmoijan on tiedettävä, mitä hän tekee. ** Tietämättömyys on itsessään turvallisuuskysymys. ** SAN: n jne. Käyttö on kuin OSX: n käyttöä, tiedät olevasi turvassa, kunnes sinua on tarpeeksi, jotta hakkerit saisivat ajattelemaan strategiaansa - ja kun kyseinen virus sammuu, se on Windows 98 uudestaan.
@Christian Sciberras Olen samaa mieltä. Valitettavasti ihmiset, jotka todella ymmärtävät nämä asiat, ovat hyvin harvinaisia, ja he ovat siellä erittäin kalliita.
@Rock, Google-haussa tuossa tiedostossa ei ole osumaa, koska kutsu on sisäkkäin eri tiedostoissa: mysqlnd_stmt_execute_store_params mysql_ps_codec.c: ssä kutsutaan [mysqlnd_stmt_execute_generate_request] (http://goo.gl/QlQHps. In viety menetelmä [mysqlnd_stmt_execute] (http://goo.gl/c9GY4). [mysqli_mysqlnd.h] (http://goo.gl/9e42S) ja [mysqlnd_libmysql_compat.h] (http://goo.gl/OnUa7) tekevät kartoituksen mysql-funktioista.
@Hendrik Brummermann Ja mysqli-koodi ei käytä mitään melusta. Jos katsot mysqli-koodia, se rakentaa oman MY_STMT-rakenteen, jossa yksittäiset parametrit * voidaan lähettää * erikseen raakakyselystä. Joten olet osittain oikeassa, on toinen vaihtoehto kuin pakeneminen mysql: lle, mutta useimmat parametrisoidut kyselykirjastot eivät käytä sitä. Lisäksi näiden kahden lähestymistavan välillä ei ole eroa turvallisuudessa, mutta MY_STMT-rakenne käyttää hieman vähemmän kaistanleveyttä / suorittimen aikaa.
#4
+5
Cut Copy
2011-08-18 02:15:49 UTC
view on stackexchange narkive permalink

Tietoja tietokantakohtaisista pakotustoiminnoista. SQL-injektiota voi esiintyä monissa tilanteissa, vaikka mysql_real_escape_string () on käytetty. LIMIT ja ORDER BY ovat todella hankalia!

Nämä esimerkit ovat alttiita SQL-injektoinnille:

  $ offset = isset ($ _ GET ['o'])? $ _GET ['o']: 0; $ offset = mysql_real_escape_string ($ offset); $ sql = "SELECT userid, käyttäjänimi FROM sql_injection_test LIMIT $ offset, 10";  

tai

  $ order = isset ($ _ GET ['o'])? $ _GET ['o']: 'userid'; $ order = mysql_real_escape_string ($ order); $ sql = "SELECT userid, username FROM sql_injection_test ORDER BY" $ order "";  

Molemmissa tapauksissa et voi käyttää 'suojaamaan kapselointia.

lähde: Odottamaton SQL-injektio (kun pakeneminen ei riitä) < - Lue tämä

#5
+4
atdre
2011-05-06 21:57:56 UTC
view on stackexchange narkive permalink

Suodattimet voidaan ohittaa ja SQL-käskyihin menevä data voi tulla useammasta paikasta kuin pelkkä käyttäjän syöttämä tieto. Syöttökohdat SQL-lähteisiin / nieluihin voidaan tallentaa (korkeamman asteen) yhtenä esimerkkinä, mutta selvästi HTTP GET -parametrit ja HTML-lomakkeiden POST-parametrit eivät ole ainoita tapoja syöttää käyttäjiä.

Parametroidut kyselyt eivät välttämättä tee SQL-käskyistäsi vapaita injektioita. Ne edellyttävät myös vaihtelevaa sidontaa, merkkijonotoimintojen / ketjutuksen poistamista ja tiettyjen tietoturvaongelmien välttämistä suurella joukolla SQL-lausekkeita.

Suurin osa kehittäjistä unohtaa myös tarkistaa kolmansien osapuolten komponentit ja muut riippuvuudet SQL-injektio-ongelmat, ja joskus eivät ymmärrä, että nämä sulkeumat voivat tehdä heidän omasta koodistaan ​​haavoittuvan.

Parasta on palkata sovellusten tietoturvakonsultointiyritys valmistelemaan hakemuksesi tuotantovalmiuteen ja kouluttaa appdev-tiimi (ä) rakentamaan sovellusten turvaohjauksia prosesseihinsa ja kehitystekniikkaansa.

#6
+3
getahobby
2011-05-07 05:00:29 UTC
view on stackexchange narkive permalink

Laajenna Hendrickin vastausta. Real_escape_string on helppo ajatella taikuudeksi, vaikka todellisuudessa se ei ole. Olen nähnyt ihmisten käyttävän tätä toimintoa, kun he haluavat käyttää intvalia tai heittää syötteen kokonaislukuun. Voit silti saada pistoksen, jos käytät paeta merkkijonoa väärässä yhteydessä.

#7
-3
xlinex
2014-10-09 03:48:51 UTC
view on stackexchange narkive permalink

Koska tarkoituksena on auttaa sinua oppimaan kirjoittamaan kunnollinen koodi eikä vain kopioida resepti, jätän joitain vihjeitä.

  • Jos jätämme koodaavia juttuja, on olemassa monilla tavoilla injektoida sql, eikä kaikkia niitä vaadita lisäämään "tai" tai ", joten Addslashes on pohjimmiltaan ontuva ratkaisu, jota rampat ja taitamattomat kehittäjät käyttävät .... (Ne, joiden ei pitäisi lukea koodia).

  • Tätä ei tapahdu paljon, mutta on olemassa vektori, jossa hyökkääjä voi hyödyntää valmiita lauseita joissakin db-moottoreissa. Se ei ole yleistä, mutta voit muistaa, että valmis lauseke käyttää lausetta, mutta taulukon metatietosarakkeen tyyppi, koko ...

  • Muu tavallinen ontuva virhe on hakujen käsittely tykkäyksillä tehdyissä kyselyissä ..... Jos löydät miten se toimii, voit tehdä joitain kiinnostavia asioita ....

Tee tutkimuksesi, älä koskaan luota syötteeseen, älä koskaan käytä mitään muuta kuin valmiita lausuntoja, ohita ketään käskee käyttämään pakenemisfu ...

Ja sinun pitäisi olla turvassa e, muista, ettei ole mitään järkeä hankkia muuta kuin mitä odotat, joten vahva kirjoitettu api on ystäväsi;).

sinun on puhdistettava tämä vastaus - oikeinkirjoitus, kielioppi, pariton muotoilu - aseta vastauksiisi hieman enemmän aikaa


Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 3.0-lisenssistä, jolla sitä jaetaan.
Loading...