PHP codeigniter SQL Injection (MSSQL) [duplikat]
Otrzymałem raport pokazujący, że moje zapytanie ma wtrysk SQL, potrzebowałbym twojej pomocy, aby zweryfikować jakiś problem:
- Używałem tego jako instrukcji wstawiania
function insert($table_name, $insert_data)
{
$this->db->set($insert_data);
if ($this->db->insert($table_name)) {
return TRUE;
} else {
return FALSE;
}
}
na przykład:
$name = 'iamklll'; $status = 1;
$insert_data = array( 'name' => $name,
'status' => $status, ); $this->model->insert('table', $insert_data);
Tego rodzaju metoda nie może zapobiec iniekcji SQL? Jeśli to nie może zapobiec, myślę, że najlepszym sposobem jest powiązanie zapytań?
Jak zapobiec iniekcji SQL, jeśli $ POST ['kolumna'] jest tablicą?
Jak przechowywać dane tak, jakby osoba wstawiała
test"><h1>eee</h1>? Czy powinienem używaćhtmlspecialcharsdo przechowywania w bazie danych?
Odpowiedzi
W twoim przypadku używasz konstruktora zapytań $ this-> db-> insert (), który generuje ciąg wstawiania na podstawie dostarczonych danych i uruchamia zapytanie. Do funkcji można przekazać tablicę lub obiekt. Wszystkie wartości są automatycznie zmieniane, tworząc bezpieczniejsze zapytania.
Moim zdaniem jest to właściwie najlepsza opcja. Lepsze niż używanie powiązań zapytań, zwłaszcza, że na dłuższą metę może zajść potrzeba zmiany MSSQL na mySQL lub jakikolwiek inny silnik i nie będziesz musiał niczego zmieniać w kodzie.
Ponieważ używasz Codeigniter 3, upewnij się, że sprawdziłeś swoje dane przed ich wstawieniem.
Użyj do tego formularza walidacji: https://codeigniter.com/userguide3/libraries/form_validation.html?highlight=form%20validation
Z twojego przykładu myślę, że odnosisz się również do ataków XXS. Jeśli tak, masz dwie możliwości, możesz to zrobić podczas sprawdzania poprawności danych za pomocą walidacji formularza przy użyciu reguły XSS. Lub możesz aktywować to globalnie w swojej aplikacji / config / config.php
$config['global_xss_filtering'] = true;
Ponieważ mówimy o ochronie Twojej aplikacji, możesz również rozważyć użycie ustawień csrf w codeigniter. Można to również zrobić w pliku config.php.
/*
|--------------------------------------------------------------------------
| Cross Site Request Forgery
|--------------------------------------------------------------------------
| Enables a CSRF cookie token to be set. When set to TRUE, token will be
| checked on a submitted form. If you are accepting user data, it is strongly
| recommended CSRF protection be enabled.
|
| 'csrf_token_name' = The token name
| 'csrf_cookie_name' = The cookie name
| 'csrf_expire' = The number in seconds the token should expire.
| 'csrf_regenerate' = Regenerate token on every submission
| 'csrf_exclude_uris' = Array of URIs which ignore CSRF checks
*/
$config['csrf_protection'] = true; $config['csrf_token_name'] = 'csrf_test_name';
$config['csrf_cookie_name'] = 'csrf_cookie_name'; $config['csrf_expire'] = 7200;
$config['csrf_regenerate'] = true; $config['csrf_exclude_uris'] = array();
W twoim przypadku użycie konstruktora zapytań jest w porządku, aby zapobiec iniekcji SQL tego, czego faktycznie szukasz.
Masz na myśli klasę Active Record. Ma własny konstruktor zapytań i ma chronić Cię przed wstrzyknięciami SQL z pudełka.
How to store the data as if the person insert test"><h1>eee</h1>
Myślę, że masz na myśli atak XSS. Uważam, że najlepszą praktyką jest usunięcie wszystkich tagów oprócz dozwolonych tagów . Myślę, że nie htmlspecialcharsbędzie to miało większego sensu tutaj, kiedy zamierzasz dokonać konwersji wstecznej na wyjściu.