Bezpečnost

Vyděsil vás titulek článku? Vlastně to bylo tak trochu cílem. Mnoho z nás totiž žije v klamné představě, že nasazení důvěryhodného SSL certifikátu a správná konfigurace webového serveru postačuje k zajištění důvěryhodného a nečitelného přenosu dat mezi serverem a klientem. Naše přesvědčení potvrzuje fakt, že na tomto předpokladu staví celý svět online byznysu.

Jak by řekli matematici – použití HTTPS protokolu je pro zajištění takové komunikace nutná, nikoliv však postačující podmínka. Díky tomu, že je HTTPS protokol páteří seriózního internetu, je také velmi zajímavý pro útočníky, kteří by jeho prolomením hodně získali.

Tento díl obsahuje praktické ukázky základních hackovacích technik jako je SQL injection, cross site scripting a nezabezpečený upload. Jedná se jen o ilustrativní výsek z desítek dalších zranitelností, které můžete na webu potkat.

Cílem bylo především ilustrovat, že útoky nejsou nikterak složité - tím spíš, že již existují automatizované nástroje, které všechno radikálně zrychlí a zdokonalí. Jednoduchost a nebezpečnost těchto útoků by měla nás, tvůrce webových aplikací, motivovat k tomu se v této oblasti vzdělávat a nenechávat vrátka pro hackery otevřená.

Many of complex applications put on top of their complexity access control logic for securing data and to limit access to certain functions. No matter if you have fully configurable ACL settings based on rights or role based access you'd probably want to test this part of application too. In order to have proper test coverage you should make it easy for you and your colleagues to test this. I have no doubts that if you ever needed to test this you already have some kind of such test support, but this article describes what kind of it I've created for myself. It might be interesting for you to compare it with your solution or inspire you to create one if you haven't done it already.

V tomto příspěvku se nechci věnovat popisu zprovoznění jCaptchy v bezpečnostní frameworku Acegi Security, jelikož toto je velmi dobře popsáno již v existujícím článku na MoroSystems weblogu. Spíš se chci zaobírat způsobem, jakým se k integraci do Acegi frameworku autoři postavili. Tento způsob mi přijde totiž přinejmenším neobvyklý. Zachovává sice zavedené principy Acegi, ale ten neodpovídá mým (ale řekl bych vcelku přirozeným) představám o tom, jak by měla captcha ve web strákách fungovat.

Je možné zajistit bezpečné sdílení HTTP session mezi oběma protokoly? Z dostupné dokumentace se dozvídáme, že nikoliv. Tento článek se zabývá možným řešením, které za jistých podmínek umožňuje bezpečně sdílet společnou session. Důvod proč se tímto problémem zabývat je jednoduchý - SSL šifrování je výpočetně nákladná věc (viz. např. Performance analysis of Secure HTTP Protocol). Proto je možná vhodné používat HTTPS pouze tam, kde je k tomu důvod (tedy např. uživatel pracuje s některými důvěrnými daty). Jistě se shodneme na tom, že na řadě webových aplikací je takto důvěrných míst pouze pár a zbytek bychom mohli hnát klidně přes protokol HTTP, čímž odlehčíme svému webovému serveru. Jenže tady narážíme na zásadní problém - nemůžeme nechráněným protokolem vyzradit identifikátor session (a naopak nesmíme akceptovat session, která vznikla přes protokol HTTP). Má tedy tato situace řešení, nebo nemá, jak se dočteme v řadě publikací?