Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 211. sraz, který proběhne v pátek 19. září od 18:00 ve Studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Na srazu proběhne přednáška Jiřího Eischmanna o nové verzi prostředí GNOME 49. Nemáte-li možnost se zúčastnit osobně, přednáškový blok bude opět streamován živě na server VHSky.cz a následně i zpřístupněn záznam.
Microsoft se vyhnul pokutě od Evropské komise za zneužívání svého dominantního postavení na trhu v souvislosti s aplikací Teams. S komisí se dohodl na závazcích, které slíbil splnit. Unijní exekutivě se nelíbilo, že firma svazuje svůj nástroj pro chatování a videohovory Teams se sadou kancelářských programů Office. Microsoft nyní slíbil jasné oddělení aplikace od kancelářských nástrojů, jako jsou Word, Excel a Outlook. Na Microsoft si
… více »Samba (Wikipedie), svobodná implementace SMB a Active Directory, byla vydána ve verzi 4.23.0. Počínaje verzí Samba 4.23 jsou unixová rozšíření SMB3 ve výchozím nastavení povolena. Přidána byla podpora SMB3 přes QUIC. Nová utilita smb_prometheus_endpoint exportuje metriky ve formátu Prometheus.
Správcovský tým repozitáře F-Droid pro Android sdílí doporučení, jak řešit žádosti o odstranění nelegálního obsahu. Základem je mít nastavené formální procesy, vyhrazenou e-mailovou adresu a být transparentní. Zdůrazňují také důležitost volby jurisdikce (F-Droid je v Nizozemsku).
Byly publikovány informace o další zranitelnosti v procesorech. Nejnovější zranitelnost byla pojmenována VMScape (CVE-2025-40300, GitHub) a v upstream Linuxech je již opravena. Jedná se o variantu Spectre. KVM host může číst data z uživatelského prostoru hypervizoru, např. QEMU.
V červenci loňského roku organizace Apache Software Foundation (ASF) oznámila, že se částečně přestane dopouštět kulturní apropriace a změní své logo. Dnes bylo nové logo představeno. "Indiánské pírko" bylo nahrazeno dubovým listem a text Apache Software Foundation zkratkou ASF. Slovo Apache se bude "zatím" dál používat. Oficiální název organizace zůstává Apache Software Foundation, stejně jako názvy projektů, například Apache HTTP Server.
Byla vydána (𝕏) srpnová aktualizace aneb nová verze 1.104 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.104 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Spotify spustilo přehrávání v bezztrátové kvalitě. V předplatném Spotify Premium.
Spoluzakladatel a předseda správní rady americké softwarové společnosti Oracle Larry Ellison vystřídal spoluzakladatele automobilky Tesla a dalších firem Elona Muska na postu nejbohatšího člověka světa. Hodnota Ellisonova majetku díky dnešnímu prudkému posílení ceny akcií Oraclu odpoledne vykazovala nárůst o více než 100 miliard dolarů a dosáhla 393 miliard USD (zhruba 8,2 bilionu Kč). Hodnota Muskova majetku činila zhruba 385 miliard dolarů.
Bylo vydáno Eclipse IDE 2025-09 aneb Eclipse 4.37. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
SELECT ENCRYPT('nějaké-heslo')
vrátí asi takovýto řetězec: MeXkFnYUhP7cw
Jakou funkcí v PHP dosáhnu stejného výsledku ? Koukal jsem na mcrypt, crypt, ale stejně jsem nenašel tu správnou password()
.
encrypt()
v MySQL je definovaná dost vágně na to, aby mohla být implementována někde jinde ještě jednou a bylo zaručeno, že obě implementace budou vracet vždy stejné výsledky.
SELECT * FROM .... WHERE ...
uděláš SELECT *, password = ENCRYPT(vstupoduzivatle) as spravneheslo FROM ... WHERE ...
a je to. Nevidim kde je problém.
Nebo taky
SELECT * FROM ... WHERE password = ENCRYPT(vstupoduzivatle) AND ...
podle toho, na co to potřebuejš...
encrypt()
i druhý parametr. Nějak se na něj zapomíná.
Jinak je samozřejmě nesmysl tahat zašifrované heslo z databáze a snažit se ho porovnávat v PHP. Na to máme SQL.
SELECT encrypt('heslo');Pokaždé to vygeneruje něco jiného. První 2 znaky jsou použitá sůl. Když výsledek uložíš do sloupce např. password, tak pro ověření stačí:
SELECT encrypt('heslo',password)=password;Z uloženého hesla
password
použije jen první 2 znaky.
encrypt()
bere z šifrovaného řetězce jen prvních 8 znaků, zbytek ignoruje. Možná proto je místo ní doporučena funkce password()
, která bere v potaz všechny znaky.
// overime existenci mailove schranky
if ($db->query("SELECT email FROM users WHERE email = '$_REQUEST[email]'")->num_rows) {
// overime spravnost zadaneho hesla, bohuzel musime primo imap pripojenim, protoze funkce encrypt v MySQL vraci pokazde jiny retezec
if ($mbox = @imap_open("{127.0.0.1:143/notls}", $_REQUEST['email'], $_REQUEST['old-password'])) {
...
Abyste chápali čeho jsem chtěl dosáhnout - chtěl jsem umožnit uživatelům měnit heslo do jejich schránky.
SELECT (ENCRYPT('ahoj','AB'));Dá vždy stejný výsledek.
ENCRYPT('ahoj','TG');(respektive jako
ENCRYPT('ahoj')
, kde se náhodně vygenerovalo to 'TG')
SELECT CASE WHEN 'TGlcRH68Dkg3g' = ENCRYPT('ahoj',SUBSTRING('TGlcRH68Dkg3g',1,2)) THEN 'rovna se to' ELSE 'NErovna se to' END AS result;Prostě si musíte vzít ty první dva znaky z uloženého encrypt-ovaného řetězce a použít je jako salt.
ENCRYPT()
- ba naopak encrypt('heslo',password)=passwordJako druhý parametr dáš to šifrované heslo v databázi.
ENCRYPT()
bere jen tolik znaků kolik potřebuje, takže ten SUBSTRING()
co jsem psal výše, je naprosto zbytečný až špatný.
if ($db->query("SELECT email FROM users WHERE email = '$_REQUEST[email]'")->num_rows) {
$_REQUEST[]
je protažen mysql_escape_string
em
Jen to prostě ukazuje na to, že používáte něco, s čím neumíte zacházet. A to prostě není dobře, protože jednou vyrobíte prasečinu, která už nevinná nebude.
Fajn, řekněme - smyšelný příklad - že najezdím ročně kolem 200 tisíc kilometrů (jakožto zahraniční řidič tahače), osobní auto umím řídit i se zavázanýma očima a mám za tu dobu za sebou jednu nehodu, kterou jsem nezpůsobil.
Vy najezdíte jakožto běžný motorista ročně kolem 15ti tisíc a máte za sebou třeba 2 zbořená auta vlastní vinou.
Jsem oprávněn Vám říkat, že používáte něco s čím neumíte zacházet a to prostě není dobře, protože jednou někoho zabijete a to už tak nevinné jako sešrotovaná auta nebude ? Je to cesta do pekel.
mysql_escape_string
em odpovídá mému požadavku a jeho formát není nikterak pozměněn.
Mě to naopak připadá jako zbytečné plácání proměnnými. Pokud vám jde čistě jen o modifikaci hodnot v gobálním poli, tak můžu samotnou fci escape_stringu přesunout s klidem do složené části SQL dotazu, kdy se nic modifikovat a znovu přiřazovat nebude.
Ale tohle, jsou jen detaily u tak jednoduché části kódu, jako je ten, který jsem napsal. Modifikace hodnot v globálním poli je možná trošku prasečina a možná se to ani nemá, ale v mém případě použití to nehraje roli.
SELECT * FROM tabulka;
", který nacházím i v komerčních aplikacích. Prostě si to někdo zjednodušil a pak už se k danému kódu nevrátil, protože mu připadal OK. Chybu to nezpůsobí hned a nemusí to způsobit nikdy, ale udržovatelnosti programu to neprospěje. Ovšem je to mnohem menší zlo, než modifikace superglobálních polí.
mysql_escape_string
k přepsání hodnoty pole z požadavku je první polovina vytvoření SQL injection. Pak se vám někde stane, že tu hodnotu escapujete dvakrát, jako opravu to escapování zrušíte a tam, kde se to escapovalo správně jednou, máte vyrobené SQL injection. Mnohem lepší je vyhnout se přepisování parametrů požadavku, vyhnout se i mysql_escape_string
a použít parametrizované dotazy.
Tiskni
Sdílej: