sql >> Database teknologi >  >> RDS >> Mysql

Hvad er den sikreste måde at tilføje html/css/js til mysql?

Ja, MySQL kan gemme enhver type tekst teknisk sikkert. Hvilket betyder, at MySQL gemmer teksten, som den er, og returnerer den igen uden at miste nogen data.

Mysql adskiller sig ikke mellem tekstens indhold, så det gør ingen forskel om det er HTML, CSS, JS-kode eller dine venners sidste e-mail.

Men hvis du udskriver teksten senere, skal du passe på, at der ikke er nogen uønsket kodeinjektion, efter du har hentet dataene fra mysql. Men det er faktisk ikke relateret til MySQL.

For at gøre din sql mere sikker skal du videregive databasehåndtaget til code>mysql_real_escape_string eller endnu bedre brug MySQLi og/eller BOB og udarbejdede erklæringer.

Din kode

Din kode ser ud til, at du prøver meget for at forhindre noget, men i sidste ende viser det sig ret ubrugeligt:

function filter($data) {
$data = trim(htmlentities(strip_tags($data)));

if (get_magic_quotes_gpc())
    $data = stripslashes($data);
    $data= strip_tags($data);

$data = mysql_real_escape_string($data);

return $data;}

Normaliser dataene, før du behandler dem

Først og fremmest bør du ændre placeringen af ​​checken for get_magic_quotes_gpc for at normalisere de data, funktionen arbejder på. Det ville være endnu bedre, hvis din applikation ikke ville stole på den, men blot nægter at virke, hvis denne mulighed er aktiveret - se denne vigtige information her om det hvis du bekymrer dig om sikkerhed.

Men for sikkerheden af ​​din postede kode, lad os først normalisere inputværdien til funktionen, før vi behandler den yderligere. Dette gøres ved at flytte markeringen til toppen af ​​funktionen.

function filter($data)
{
   // normalize $data because of get_magic_quotes_gpc
   $dataNeedsStripSlashes = get_magic_quotes_gpc();
   if ($dataNeedsStripSlashes)
   {
     $data = stripslashes($data);
   }

   // normalize $data because of whitespace on beginning and end
   $data = trim($data);

   // strip tags
   $data = strip_tags($data);

   // replace characters with their HTML entitites
   $data = htmlentities($data);

   // mysql escape string    
   $data = mysql_real_escape_string($data);

   return $data;
 }

I denne modificerede funktion er de magiske citater (som du ikke bør bruge) flyttet til toppen af ​​den. Dette sikrer, at uanset om denne mulighed er slået til eller fra, vil data altid blive behandlet ens. Din funktion gjorde det ikke, den ville have skabt forskellige resultater for de samme data, der blev sendt. Så dette er blevet rettet.

Flere problemer med din funktion

Selv funktionen ser bedre ud nu, den har stadig mange problemer. For eksempel er det uklart, hvad funktionen rent faktisk gør. Den gør mange ting på én gang, og nogle af dem er modstridende:

  • Det fjerner HTML-tags, hvilket er et tegn på, at $data bør ikke indeholde HTML
  • Men så konverterer du teksten til $data at have faktisk indeholde HTML-enheder.

Så hvad skal dataene være? HTML eller ej? Det introducerer ikke mere sikkerhed, hvis tingene bliver uklare, fordi det vil gavne, at der kommer fejl ind i dit program og i sidste ende endda passerer dine sikkerhedsforanstaltninger.

Så du skal bare smide koden væk og overveje følgende:

  • Hvis input til din applikation er ugyldigt, skal du ikke filtrere det. Undgå i stedet yderligere brug af ugyldige input. Så du har brug for en funktion til at validere input, før du bruger den.
  • Lad være med at ændre data, bare fordi du tror dette kan gøre noget mere sikkert. I stedet ændres og indkodes data, hvor det er nødvendigt og passende.
    • Få din ansøgning til kun at fungere med magiske anførselstegn slået fra. Det frarådes stærkt at stole på denne funktion. Og så er der ingen grund til at tjekke for det hele i din kode.
    • For at gemme noget sikkert i databasen, skal du undslippe dataene, før du kun bruger dem i forespørgslen. Ikke et andet sted i din ansøgning. Brug Forberedte udsagn til det.
    • Ingen grund til at skændes med dataene, før du lægger dem ind i databasen, hvis de er gyldige. Men du skal kode den korrekt, når den udsendes til websiden . Og kun dér ved en applikation, i hvilken kodning dette skal være. Det ved du ikke, når du lægger dataene ind i databasen.

Så hvis du vil gøre din kode mere sikker, handler det ikke om at smide en masse funktioner på nogle data, fordi du tror, ​​de er sikkerhedsrelaterede. Ved at gøre det gør du ikke din software mere sikker, men mindre sikker.

  1. Stol aldrig på brugerdata.
  2. Sørg for, at data er i det format, du har brug for dem forudgående behandling .
  3. Brug det rigtige værktøj til jobbet på det rigtige sted.
  4. Brug aldrig værktøjer til at gætte. Få viden i stedet, som ikke kun betaler sig sikkerhedsmæssigt.



  1. Oracle sql til at tælle forekomster af forskellige værdier i en enkelt kolonne

  2. Det ultimative emoji-kodningsskema

  3. Gendannelse af en databasesikkerhedskopi i OpenCart 1.5

  4. SQL Server Database Server Hardware Upgrade Case Study