Patryk27
2017-05-15 20:02

Mieliśmy ostatnio w pracy inwentaryzację przy wykorzystaniu aplikacji, którą napisałem.

W pewnym momencie u jednej z ekip (sklep ma trochę metrów, zatem byliśmy podzieleni na cztery ekipy) zaczęły pojawiać się podejrzane stany produktów. Takie w rodzaju minus pięć miliardów sztuk :) Była to jedyna drużyna, u której ten błąd występował, a ponadto znajdował się w niej szef, zatem przewinąłem moją flanelową koszulę +64 do programowania na drugą stronę i, zakasawszy rękawy, odpaliłem PhpStorma.

Aplikacja jest stroną internetową i wykorzystuje do komunikacji oraz zapisywania danych do localStorage json (zaskoczenie), zatem moje pierwsze podejrzenie opierało się o istnienie jakiegoś bugu na linii serializacja danych - przetwarzanie.

chrome json int bug w Google (:D) nic ciekawego nie zwróciło, zatem stwierdziłem, że nie będę tak na sucho szukał sam nie wiedząc tak właściwie czego i usiadłem obok tej ekipy, przyglądając się temu, co oni takiego podejrzanego robią, że wywołują błąd.

Hehe, nikt nie zgadnie.

Raz na jakiś czas przypadkowo skanowali kod kreskowy w pole Liczba sztuk produktu :--DD

(jeden był przy komputerze, drugi latał po sklepie ze skanerem, dlatego ten ze skanerem nie widział, co się dzieje na monitorze)

A że taki kod kreskowy przeważnie jest całkiem długi (z rodzaju 314159265359), to i biedny 32-bitowy int się overflował, co przełożyło się na nieprawidłowe działanie aplikacji.

Dodałem odpowiednie zabezpieczenie i magicznie więcej błędów nie było.
Jak to szło: przychodzi tester do baru...

#programowanie #tester #testowanie #php #achciużytkownicy

Patryk27

@Azarien: ponieważ wtedy można tę aplikację bez problemu odpalić nawet i na tablecie z podpiętym czytnikiem, bez zabawy w "ooo, widzę kolega ma Maczka - cóż, nie przydasz nam się". Poza tym jestem web developerem, nie pamiętam już czasów, gdy tykałem aplikację okienkową, a w robocie jestem jednym programistą :-P

Azarien

to ludzie używali prywatnych urządzeń do pracy?

nrm
2017-01-21 16:36

Dzień Dobry, jestem nowy. Jeszcze nic tu nie kumam ale się ogarnę. Na powitanie zrobiłem mema ;)

#php #laravel #symfony #heheszki

lukas_gab

Chyba, nie dla mnie te treści, bo ani mnie nie śmieszy ten rodzaj humoru, a i też nie do końca rozumiem tą dyskusję. Nie wiem, czy to już ten czas, że przestaje się rozumieć trendy i nowe reklamy w tv... ale do cholery nie mam nawet 30 lat ...

Doggye

Ze wzgledu na moj nick i ulubiony fw czuje sie podwojnie dotkniety :p

bordeux
2016-10-18 01:40

Przyszedłem tutaj pohejtować CodeIgniter.
Po tym jak poznałem Symfony 2, to się dowiedziałem że byłem dupa a nie programista. Poznałem tam wzorzec DI, ORM'a, service locator itp. Po prostu wszedłem w poziom zaawansowany programowania, zrozumiałem co to prawdziwe programowanie w PHP.

Za 2 tygodnie dostanę projekt w CodeIgniter. Dzisiaj czytałem dokumentacje tego frameworka. I jestem w wielkim szoku. XXIw, PHP 7.1 już mamy, a ten twór z PHP 4 jeszcze istnieje i jest nadal rozwijany. Jak dzisiaj czytam tą dokumentacje (wersja 3) to jestem w szoku, że nie wiem co powiedzieć. Po prostu czuje się jakbym przeniósł się w czasie, gdy pisałem gówno-code.

To powinno zostać usunięte z sieci, aby programiści nie przyswajali złych nawyków i wzorców. Teraz sram na miętowo bo domyślam się jaki kod otrzymam za te 2 tygodnie :| WC będzie cały czas przeze mnie rezerwowany. W sumie już mogę myśleć by nie przenieść biurka do WC, by mieć blisko.

! Przepraszam za taki gownowpis, ale chcialem to komuś powiedzieć publicznie.

#php #hejt #gownowpis #whocares

Spine

@bordeux: Oczywiście, że szybko się pisze w PHP. Ale jednak po swoich doświadczeniach z PHP'em (trafiłem do projektu rozwijanego wcześniej przez stażystów) śmiem twierdzić, że lepiej gdy ograniczenia języka bardziej pilnują ładu w kodzie ;) No i w Javie też łatwiej zrobić refaktor nie powodujący błędów, bo IDE z reguły nie wie jaki typ argumentu podaję do metody (chyba, że określimy typ argumentu w deklaracji, a w PHP nie zawsze to robią). Konieczność zastosowania jakiegoś mechanizmu szablonów, zamiast możliwości przeplatania kodu z widokiem, to chyba też na plus Javy.

bordeux

@Spine: z tym sie zgadzam w 100% :)

Koziołek
2016-04-02 15:34

Pisanie 1 kwietnia o php wydawało mi się dość hm... dziwne, ale mamy już 2 kwietnia zatem...

http://koziolekweb.pl/2016/04[...]rora-htmlowego-w-wordpressie/

#koziolekweb #blogowawiosna #php ← tak tu jest tag #php

Koziołek

@no_solution_found: Cóż widziałem niedawno php7... nadal nie jest dobrze. Zresztą WP mógłby w końcu trochę się ogarnąć i wersję 5 wypuścić już bez narzutu historycznego.

no_solution_found

@Koziołek: nie jest dobrze, ale już jakieś sensowne systemy w tym powstają. PHP 7 to w większość optymalizacja i wywalenie przestarzałych bibliotek z języka. WP nie wypuści pewnie niezgodnej wersji wstecz, bo wtedy odetną się od milionów pluginów/szablonów, które to są ich siłą napędową.

Shalom
2015-10-13 14:03

Ciekawostka, na którą wpadliśmy podczas CTFa w ostatni weekend. PHP ma dwa operatory porównania -> == jak każdy normalny język oraz ===. Różnica między nimi jest taka, że ten pierwszy (którego pewnie użyłoby 95% programistów którzy tylko odświętnie piszą coś w php) wykonuje automatyczną konwersję typów. Niby nie wydaje się to jakieś groźne, ale ta konwersja jest dość zaawansowana. Na przykład string zawierający same liczby jest konwertowany na liczbę, nawet jeśli porównujemy go z innym liczbowym stringiem, więc konwersja zachodzi nawet jeśli nie jest konieczna do wykonania porównania.
Można to wykorzystać w dość ciekawy sposób -> string postaci XeYZV gdzie X,Y,Z,V są liczbami jest automatycznie konwertowany do floata. Jeśli więc za X podstawimy 0 to dostaniemy liczbę 0e.... czyli 0*10^cośtam^ a to zawsze wyniesie 0. Wynika z tego że w PHP porównanie:

"0e1234" == "0e5678"

zwróci nam true. To oznacza że jeśli przypadkiem hash waszego hasła w bazie danych zaczyna sie od 0e i dalej zawiera same liczby to takie porównanie go z dowolnym innym hashem tej postaci zwróci true :)

Zainteresowanych podobnymi ciekawostkami zapraszam do czytania https://github.com/p4-team/ctf :)

#exploit #p4 #php #ctf

Koziołek

@Gynvael Coldwind: o przydatne... szczególnie, jak ktoś mało robi w phpie...

Patryk27
2015-10-03 13:10

Co to #PHP to ja nawet nie...

Mamy firmową wtyczkę (skądinąd napisaną przeze mnie) służącą do aktualizacji produktów oraz zamówień z/do Magento na podstawie naszej głównej bazy danych.
Wywoływana jest ona dwojako, można z poziomu żądania HTTP bądź z poziomu skryptu na serwerze (bardziej verbose + cron).

Ze wstępu to tyle, sytuacja z dzisiaj: aktualizacja przez HTTP działa, uruchomienie przez skrypt nie - jest prawie że natychmiast terminowany bez żadnego komunikatu - a potrzebuję mieć dokładny podgląd na żywo z procesu aktualizacji.

Zabieram się więc za debugowanie.

Madżento ma klasę Mage_Core_Model_App, która jest jedną z pierwszych wywoływanych przy inicjacji tegoż systemu - znajduje w niej metoda o jakże zwięzłej nazwie init.
Dupa debugging doprowadziło mnie do tego, że PHP wyłącza się zaraz po linijce $this->_config->init($options);.

Kilka sekund później jestem już w pliku Mage_Core_Model_Config, kolejne dupa debugging i terminuje się przy $this->loadModulesCache();, w taki sposób przeleciałem przez kilka następnych klas, aż trafiłem do Magento_Db_Adapter_Pdo_Mysql.

Ta magiczna klasa Magento_Db_Adapter_Pdo_Mysql dziedziczy z Varien_Db_Adapter_Pdo_Mysql i teraz zaczyna się magia.
W ramach rozkładania rąk oraz techniki extended dupa debugging postanowiłem dodać na samej górze die("included");, wywalić połowę pliku i zobaczyć czy się wczyta (z PHP nigdy nie wiadomo).
Wracam do konsoli, *strzałeczka w górę, enter** i widzę ładny komunikat included w konsoli.
Ctrl+Z, znów uruchamiam aktualizację i tym razem nie działa.

W tej chwili przed oczami miałem jeden, wielki bluescreen, bo:
1.Nie może być to błąd składniowy, ponieważ uruchomienie przez żądanie HTTP działa za każdym razem bez problemu, sklep także nie rzucał żadnych wyjątków.
2.A żadna z tych metod nawet nie jest wywoływana, jako że na samej górze jest die, więc jakim cudem usunięcie którejś może cokolwiek zmienić?

Wróciłem do extended dupa debugging wywalając z kodu po kolei po jednej metodzie (zrobiwszy ofc. uprzednio kopię oryginału) i patrzę, kiedy komunikat included się znowu pojawi.

Doszedłem do tego, że takie coś (fragment metody) powoduje terminację PHP:

if (!is_array($table)) {
    $table = array($table => $table);
}
 
// get table name and alias
$keys       = array_keys($table);
$tableAlias = $keys[0];
$tableName  = $table[$keys[0]];
 
$query = sprintf('UPDATE %s', $this->quoteTableAs($tableName, $tableAlias));

Ale to działa już ok:

if (!is_array($table)) {
    $table = array($table => $table);
}
// get table name and alias
$keys       = array_keys($table);
$tableAlias = $keys[0];
$tableName  = $table[$keys[0]];
$query = sprintf('UPDATE %s', $this->quoteTableAs($tableName, $tableAlias));

(usunąłem tylko dwa entery!)

Nie muszę chyba wspominać, że w tym momencie najbardziej na świecie pragnąłem przepisać się do jakiejś akademii sztuk pięknych w Zimbabwe, byleby być z dala od tego PHPowego interpretatora...

Anyway, przywróciłem oryginalne pliki, service restart php5-fpm i już wszystko działa...

  • dla tych niepracujących w szelu - jest to uruchomienie poprzedniej komendy, w tym wypadku skryptu uruchamiającego odpowiedni plik PHP odpowiedzialny za aktualizację.
    #magento #php
Patryk27

@Rev: (nie)stety póki co nie, ale jeśli się powtórzy to zbiorę wszystkie dane.

Rev

@Patryk27: Nawiązując do tego co mówił @MSM: niedługo powinniśmy wrzucić PDFa z naszym artykułem do "Programisty" o zadaniu z CTF-a o analizie core dumpa procesu PHP właśnie. Może bym się pobawił jeszcze raz jakby udało ci się podrzucić coś do analizy :P.