Ve Würzburgu dnes začala konference vývojářů a uživatelů desktopového prostředí KDE Akademy 2024. Sledovat lze také online (YouTube, Mastodon, 𝕏, …)
Byla vydána nová major verze 14 svobodného systému pro řízení přístupu k síti (NAC) PacketFence (Wikipedie). Přehled novinek v oznámení o vydání. Pro uživatele předchozích verzí jsou k dispozici poznámky k aktualizaci.
Jak nahrávat zvuk z webového prohlížeče na Linuxu s PipeWire pomocí Nahrávání zvuku (Sound Recorder) a Helvum případně qpwgraph, článek na webu Libre Arts.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.9.
České bezpečnostní instituce, jmenovitě Vojenské zpravodajství (VZ) a Bezpečnostní informační služba (BIS), ve spolupráci s americkou Agenturou pro kybernetickou a infrastrukturní bezpečnost (CISA), Federálním úřadem pro vyšetřování (FBI), Národní bezpečností agenturou (NSA) a dalšími mezinárodními partnery ze Spojeného království, Austrálie, Kanady, Německa, Nizozemska, Estonska, Ukrajiny a Lotyšska vydaly upozornění (
… více »Byla vydána (𝕏) srpnová aktualizace aneb nová verze 1.93 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.93 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Společnost Laravel stojící za stejnojmenným open source PHP frameworkem získala investici 57 milionů dolarů od společnosti Accel. Především na Laravel Cloud.
Byla vydána verze 1.81.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Řešena je také zranitelnost CVE-2024-43402. Vyzkoušet Rust lze například na stránce Rust by Example.
Vládní CERT vydal (𝕏) novou verzi nástroje maldump. Ten slouží k extrakci souborů z karantén různých antivirových programů. A to jak z živého systému, tak z obrazu disku.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
HTTP Error 403: The service you requested is restricted
The service you requested is restricted and not available to your browser
The restriction can be based on your IP-address, hostname, browser software, time-of-day or other variables. Most likely you requested a service that was made available to a restricted subnet.
Příklad takové stránky je třeba blog.cz. Zkoušel jsem i traceroute a zdá se, že požadavek k serveru normálně dojde, pokud to správně chápu.
$ traceroute www.blog.cz
traceroute to blog.cz (217.31.54.174), 30 hops max, 40 byte packets
1 10.10.133.78 (10.10.133.78) 223.789 ms 249.924 ms 206.639 ms
2 10.10.133.66 (10.10.133.66) 626.631 ms 319.937 ms 199.988 ms
3 10.10.133.141 (10.10.133.141) 199.967 ms 249.935 ms 199.973 ms
4 10.10.133.1 (10.10.133.1) 206.635 ms 249.940 ms 749.965 ms
5 vl914.rcnR04i.oskarmobil.cz (217.77.160.26) 299.971 ms 199.924 ms 256.635 ms
6 po1-0.sitR00i.oskarmobil.cz (217.77.160.62) 199.969 ms 249.929 ms 416.637 ms
7 ge0-3.gtsR00i.oskarmobil.cz (217.77.160.18) 326.636 ms 226.600 ms 233.306 ms
8 nix-m.backbone.ignum.cz (194.50.100.8) 903.301 ms 343.262 ms 209.969 ms
9 chikuma.jyxo.com (217.31.54.174) 226.631 ms 223.266 ms 476.643 ms
28.6.2008 17:26
Jendа | skóre: 78
| blog: Jenda
| JO70FB
29.6.2008 23:32
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
Tak zkuste telnet na port 80 na daném serveru a uvidí se ... jak to maj vychytaný 
$ telnet www.etree.org 80 Trying 152.46.7.81... Connected to etree.org. Escape character is '^]'.Vypadá to, že to takhle funguje u všech stránek co jsem zatím zkoušel, všechny i ty co jsem tu předtím vypisloval se po připojení rozběhly. Telnet to asi nějak prošťouchne. Ještě uvidím na jak dlouho. Napadá vás, co by šlo případně přes telnet zjistit? Nevím co do telnetu psát. Díky
GET / HTTP/1.0a stlacit 2x Enter; mal by si dostat nejaku odpoved zo servera.
GET / HTTP/1.0 Host: www.etree.orga 2× <Enter>, HTTP servery většinou používají virtual host a pokud nezadáte jméno, dostanete nějakou defaultní stránku (a proxy po cestě rozhodně nezjistí, kam se vlastně připojujete, takže nemůže nic filtrovat).
GET / HTTP/1.1 Host: www.etree.org Connection: closenakolko header field
Host je definovany az protokolom HTTP 1.1.
HTTP/1.0 (a to Host není), musí být u requestu uvedena verze HTTP/1.1. Deklarací HTTP/1.1 totiž netvrdíte, že podporujete nebo používáte všechny jeho vymoženosti.
Request-Header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields may be given the semantics of request header fields if all parties in the communication recognize them to be request header fields. Unrecognized header fields are treated as Entity-Header fields.Deklarací
HTTP/1.1 klient tvrdí, že je alespoň na minimální úrovni kompatibilní s HTTP 1.1 (což na klientské straně znamená např. povinnou hlavičku Host). Jinak HTTP 1.1 vzniklo z velké části standardizací právě těch nových a experimentálních hlaviček HTTP 1.0, jako Host nebo Connection, takže se zákonitě musely používat hlavičky nedefinované v HTTP 1.0 před standardizací HTTP 1.1.
Ostatně protokol, který by nebyl dopředně kompatibilní a nepovoloval rozšíření, by byl celkem k ničemu – nebylo by možné jej prakticky rozvíjet a nové verze protokolu by nevycházely z praxe (co se používá), ale byla by to pouze teoretická práce (nikdo to nepoužívá, ale určitě by v protokolu chtěly tohle).
Tak si přečtěte ještě RFC 2145, sekci 2.3:
An HTTP client SHOULD send a request version equal to the highest version for which the client is at least conditionally compliant, and whose major version is no higher than the highest version supported by the server, if this is known. An HTTP client MUST NOT send a version for which it is not at least conditionally compliant.
An HTTP client MAY send a lower request version, if it is known that the server incorrectly implements the HTTP specification, but only after the client has determined that the server is actually buggy.
Host, takže tam nemá co dělat.
Nová a experimentální? Devět let po RFC 2616 a jedenáct a půl roku po RFC 2068? To opravdu ani trochu nevypadá jako účelová konstrukce vymyšlená k obhájení neobhajitelného…
Mimochodem, docela by mne zajímalo, kolik z těch, kdo dnes lpí na HTTP/1.0, si je vědomo, jaký je časový odstup mezi RFC 1945 (specifikace HTTP/1.0) a RFC 2068 (první verze specifikace HTTP/1.1).
Mimochodem, docela by mne zajímalo, kolik z těch, kdo dnes lpí na HTTP/1.0, si je vědomo, jaký je časový odstup mezi RFC 1945 (specifikace HTTP/1.0) a RFC 2068 (první verze specifikace HTTP/1.1).Hlasim sa medzi tych, co by si priali, aby aspon fungovalo to http/1.0. Casovy rozdiel som nikdy neskumal. However, je vyrazne jednoduchsie implementovat prijatie http message tak, ze prijmem cely msg a az potom zacnem parsovat, zatial co persistent connections musim on-the-fly parsovat hlavicku, aby som zistil Content-Length. Uznavam, vo vseobecnosti nie je dobry pristup tahat cely msg do pamate (hehe, co ak je odpovedou DVD ISO image?), ale v specialnej aplikacii, ktoru som robil, toto nebolo issue. Zaroven nie je potrebne riesit 1xx status codes, a pod. Dost mi vsak liezlo na nervy, ked som jednemu velmi rozsirenemu open source browseru z pozicie http servera povedal, ze ovladam HTTP/1.0 a prajem si vypnute keep-alive a prosim ho o uzatvaranie spojenia po kazdom msg, a on mi napriek tomu cpal HTTP/1.1 requesty, pouzival http keep-alive, a spojenia zasadne neuzatvaral. Takze nelipnem striktne na http/1.0, ale ked je klient ci server on poziadany, mal by fungovat.
Host rozhodit a maximálně ji bude ignorovat. Pokud by ji ignoroval, s HTTP 1.1 bych u něj asi neuspěl o nic lépe.
aby mohl "hyperkorektně" použít hlavičku Host
To hyper- je tam zcela nadbytečné, proč nenapíšete prostě jen korektně?
Pokud někdo uvede HTTP/1.1 tak tím tvrdí, že tento protokol ovládá, ale to při ruční komunikaci zpravidla není pravda
Smím se zeptat proč?
použít HTTP/1.0 a uvést hlavičku Host tam, protože vzhledem ke stáří HTTP/1.0 kterým se tu někdo oháněl je jasné, že sever to pochopí
Jasné to zdaleka není. A nejde tu ani tak o stáří HTTP/1.0, ale o to, že (1) první verze specifikace HTTP/1.1 vyšla před jedenácti a půl lety, takže to není nějaká horká novinka, které bychom se měli bát, a (2) mezi specifikací HTTP/1.0 a první verzí specifikace HTTP/1.1 uběhlo pouhých sedm měsíců a v samotném RFC 1945 je zmínka, že se očekává brzké nahrazení.
Ostatně protokol, který by nebyl dopředně kompatibilní a nepovoloval rozšíření, by byl celkem k ničemu – nebylo by možné jej prakticky rozvíjet a nové verze protokolu by nevycházely z praxe (co se používá), ...No, HTTP protokol je sice krasne otvoreny, dopredne kompatibilny a uzastne flexibilny, ale aj velmi nepresny, neuveritelne vagny a na niektorych miestach dokonca specifikacia odporuje sama sebe. Ak webdizajneri vedia, ze vebove prehliadace predstavuju "vitaztvo pocitaca nad clovekom", developeri webovych servero, proxy serverov a http klientov nie su na tom o nic lepsie. A vsetci, co sa zaoberaju bezpecnostou webovych aplikacii vedia, ze 95% bezpecnostnych problemov webovych applikacii suvisi prave s tym, ze ako prenosovy protokol je pouzite prave HTTP. Vsetky tri uvedene role som si mal tu moznost do sytosti vyskusat.
A vsetci, co sa zaoberaju bezpecnostou webovych aplikacii vedia, ze 95% bezpecnostnych problemov webovych applikacii suvisi prave s tym, ze ako prenosovy protokol je pouzite prave HTTP.To bych tedy těch 95 % chtěl vidět. Bezpečnostní problémy webových aplikací zpravidla znamenají ovlivnění serverové aplikace nebezpečným vstupem (např. SQL injection, PHP include apod.), další jsou pak problémy důvěryhodnosti dat v prohlížeči (XSS a různé další způsoby komunikace a kradení údajů mezi doménami). Nic z toho s HTTP nesouvisí. Další druh problému může být buffer overflow, ale to zase s HTTP nijak nesouvisí. Z hlediska bezpečnosti je nešťastný třeba pohrobek HTTP 1.0, kdy ukončení spojení ze strany serveru může být regulérní konec přenosu (místo aby bylo nutné vždy určovat délku entity).
29.6.2008 00:09
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
HTTP/1.0 307 OK Location: http://a.redirect.info/blabla/(na stranku informujucu o povinnosti nastavit si DHCP; je tam formular, predvyplneny na nieco v zmysle "ano, rozumel som, nastavim si dhcp"; po jeho odoslani sa pripojenie obnovi. Nemohlo by to byt nieco podobne v Tvojom pripade?
http://www.blog.cz/ GET / HTTP/1.1 Host: www.blog.cz User-Agent: Mozilla/5.0 (X11; U; Linux i686; cs; rv:1.9) Gecko/2008052912 Firefox/3.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: cs,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive HTTP/1.x 403 not authorized Server: XMS (724Solutions HTA XMP_40_M1_B035 20080226.125455) Date: Mon, 30 Jun 2008 18:06:03 GMT Accept-Ranges: bytes Content-Type: text/html Content-Length: 1258 ----------------------------------------------------------Ale moc jsem z toho nevyčetl. Žádné přesměrování jako v tvém případě se nekoná. Prostě 403 a konec.
30.6.2008 21:23
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Server: XMS (724Solutions HTA XMP_40_M1_B035 20080226.125455)Jenže na blog.cz ve skutečnosti běží Apache. Právně znalí lidé, není tohle klasifikovatelné jako porušování listovního tajemství nebo tak něco?
Moj drahy provider v snahe zabranit pouzivaniu routerov v bytoch, forcuje pouzivanie DHCP; takze ak sa z ich pohladu koncove zariadenie nekonfiguruje pomocou DHCP, akykolvek http traffic presmeruju ...Jak se jim to daří? Vždyť i takový router umí DHCP (na jednom rozhraní klient, na druhém server). Dokud nerozbalí packet, tak nemůžou nic vědět (oni nemůžou nic vědět ani tak, protože virtualizační nástroje můžou taky dělat NAT).
traceroute --tcp --port=80 www.blog.cz), implicitní je přes UDP, na což se HTTP filtry samozřejmě nechytají.
Mně se to stává taky, a to i na mobilu (Nokia E51 browser). Přes Operu Mini samozřejmě běhá všechno. A také je tento problém jen u Vodafonu Na stálo. Pomáhá jen odpojit se a znovu připojit, to změní IP adresu a skrytou stránku zpřístupní
Tiskni
Sdílej:
