Utvecklare på Jfokus men inte på AppSec

Igår och idag har jag bevistat Javakonferensen Jfokus. Föredraget om 97 Things Every Programmer Should Know var intressant. Jag valde det framför det enda bidraget om säkerhet.

Men under konferensen var det bara en sak som verkligen fick mig att rycka till. Det var när Dan North frågade publiken "Are there any developers here?"

... och hela föreläsningssalen räckte upp handen.

Så brukar det nämligen inte se ut på andra konferenser jag går på. Samma fråga ställs men bara två-tre händer sträcks upp. Där har vi som community en utmaning. Applikationssäkerhet måste bli sexigare.

Vägen dit tror jag är att låta utvecklare få prova att knäcka system. Under de kurser jag ger inom applikationssäkerhet ser jag nämligen hur det glittrar i ögonen på alla som får bryta sig in i en applikation. Att lära sig hacka system är helt enkelt sexigt.

Säkerhet i Java EE 6, HttpOnly och session cookies

Jag bloggade tidigare om nya säkerhetsfunktioner i Java EE 6 HttpServletRequest. Nu har turen kommit till säkerhetsnyheterna kring cookies, eller kakor som jag gillar att kalla dem :).

För er som bara vill läsa om det nya är det bara att hoppa till rubriken "Nyheter i Java EE 6".

Http saknar session och tillstånd

Http som protokoll har ju varken sessionshantering eller tillstånd (state). Kakor används för både och. Internet Explorer sätter de hårdaste begränsningarna på hur mycket tillstånd som får lagras i kakor:

• Max 4 kB per kaka i IE6 och IE7
• Max 50 kakor per sajt i IE6, IE7 och IE8

Alla andra webbläsare tillåter större och fler kakor. Men för sessionshantering så räcker 4 kB och en kaka bra. Det man snarare behöver arbeta med är sessionskakans säkerhet.

Hot mot sessioner i kakor

Det finns flera hot mot sessionshantering i kakor:

• Session hijacking. XSS kan stjäla sessioner direkt ur sidan eftersom document.cookie normalt sett är tillgänglig för JavaScript. Därtill kan okrypterade kakor stjälas direkt på nätet.
• Cookie replay. Sessionskakan kan öppna upp en avslutad session på nytt. Attackeraren återanvänder den helt enkelt.
• Cookie poisoning. Applikationen använder inte pseudoslump på ett bra sätt vid sessionshanteringen vilket tillåter en attackerare att generera en giltig sessionskaka.

Skydd av sessioner i kakor

För att skydda sina sessionskakor (och andra kakor för den delen) finns ett antal tekniker:

• HttpOnly-attributet. Genom att markera sin sessionskaka som HttpOnly så ser webbläsaren till att JavaScript inte får läsa den. XSS-stöld av kakan blir alltså omöjligt. Det har tagit tid för webbläsarna att få ordning på det här. T ex så kunde AJAX-anrop få tillgång till alla Http-headers där ju också kakorna finns. Så XSS med AJAX kunde kringå HttpOnly. Java EE 5-API:et har inte stöd för HttpOnly.
• Secure-attributet. Genom att markera sin sessionskaka som Secure så ser webbläsaren till att kakan bara skickas vid https-anrop, dvs krypterat.
• Pseudoslump. Sessionskakor ska genereras med pseudoslump, så kallat salt. Hela den hanteringen är så pass svår att man inte ska sköta sin egen sessionshantering. Låt din applikationsserver göra det åt dig.

Nyheter i Java EE 6

Första nyheten i Java EE 6 är att HttpOnly numer stöds av API:et! I klassen Cookie hittar vi:

public void setHttpOnly(boolean isHttpOnly)

public boolean isHttpOnly()

Därtill kan man via sin servlet-kontext sätta hur sessionshanteringen ska ske. I ServletContext finns från och med nu:

void setSessionTrackingModes(Set<SessionTrackingMode> sessionTrackingModes)

... där man sätter en eller flera SessionTrackingMode som man vill ha. SessionTrackingMode är en enum som erbjuder sessionshantering med:

• COOKIE. Precis vad det låter som -- sessionshantering med kakor. Mer om det nedan.
• SSL. SSL-sessionen används som http-session. Det kräver förstås att det är en https-koppling, formellt att ServletRequest.isSecure() returnerar true.
• URL. Sessions-id följer med som en URL-parameter.

Sä här sätter man sessionshanteringen till SSL:

ServletContext context = event.getServletContext();

EnumSet<SessionTrackingMode> modes =

EnumSet.of(SessionTrackingMode.SSL);

context.setSessionTrackingModes(modes);

Konfigurera sessionskakan

Sessionshantering med kakor är ju inget nytt som sådant och vår gamla JSESSIONID hänger med än. Men nu kan vi konfigurera bättre hur applikationsservern ska sköta JSESSIONID. Det gör man med SessionCookieConfig som är ny i Java EE 6. Intressantast i det interfejset är förstås:

void setHttpOnly(boolean httpOnly)
void setSecure(boolean secure)

På så vis kan vi säga åt appservern att bara skicka JSESSIONID-kakan krypterat och med HttpOnly-attributet på.

Google-hacket och sårbara IE-versioner

Eftersom det är så mycket prat om det så kallade Google-hacket och vilka versioner av Internet Explorer som är sårbara så återpublicerar jag här Microsofts egen information:

	Windows 2000	Windows XP	Windows Vista	Windows 7
Internet Explorer 6	Exploitable	Exploitable (current exploit effective for code execution)	N/A (Vista ships with IE7)	N/A (Windows 7 ships with IE 8)
Internet Explorer 7	N/A (IE 7 will not install on Windows 2000)	Potentially exploitable (current exploit does not currently work due to memory layout differences in IE 7)	IE Protected Mode prevents current exploit from working.	N/A (Windows 7 ships with IE 8)
Internet Explorer 8	N/A (IE 8 will not install on Windows 2000)	DEP enabled by default on XP SP3 prevents exploit from working.	IE Protected Mode + DEP enabled by default prevent exploit from working.	IE Protected Mode + DEP enabled by default prevent exploit from working.

Penetrationstesta med Selenium

En god vän inom OWASP och utvecklare av fuzzern JBroFuzz, Yiannis Pavlosoglou, gav igår en presentation om penetrationstesting mha Selenium. Bra grejer.

Hans presentation inkl lite exempelkod i Perl finns här (pdf).

De demotester han körde mot stackars WebGoat finns på YouTube. Först brute force-tester av inlogging:

Sen SQL injection-tester:

Seminariekväll 21/1: De stora protokollen

Äntligen är det dags för seminariekväll, denna gång om "De stora protokollen". Normalt ägnar vi mycket tid åt säkerheten i applikationslagret. Samtidigt bygger allt på säkerheten i de underliggande nätverksprotokollen. Vi ägnar därför en kväll åt dem. Tre föredragshållare från tre organisationer kommer berätta om säkerhet i BGP, DNSSEC och SSL/TLS.

Stiftelsen för Internetinfrastruktur (.SE) och föreningen SNUS (Swedish Network Users' Society) står som värdar och sponsrar med lokal och förtäring. Det tackar vi givetvis varmt för!

Pdf-inbjudan hittar ni här.

Program

17.30 Mingel och förtäring

18.00 Håvard Eidnes (UNINETT/NORDUnet): BGP (Border Gateway Protocol)

18.45 Rickard Bellgrim (.SE): DNSSEC

19.30 Fredrik Hesse (Svenska Spel): SSL/TLS

20.10 Slut, eftersnack på någon pub i närheten

Datum

Torsdag 21/1

Plats

.SEs hörsal, Ringvägen 100 A, 9 tr, Skanstull, Stockholm

Anmälan

Senast 18/1, dvs på måndag

Se till att vara med på OWASP-listan (=medlem) och mejla sen anmälan till mig på john.wilander@owasp.org.

Vi ses!

2009 års främsta hacktekniker

Jeremiah Grossman har koordinerat omröstningen om de främsta webbhackteknikerna 2009. Resultatet:

1. Creating a rogue CA certificate
Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger

2. HTTP Parameter Pollution (HPP)
Luca Carettoni, Stefano diPaola

3. Flickr's API Signature Forgery Vulnerability (MD5 extension attack)
Thai Duong and Juliano Rizzo

4. Cross-domain search timing
Chris Evans

5. Slowloris HTTP DoS
Robert Hansen, (additional credit for earlier discovery to Adrian Ilarion Ciobanu & Ivan Ristic - “Programming Model Attacks” section of Apache Security for describing the attack, but did not produce a tool)

6. Microsoft IIS 0-Day Vulnerability Parsing Files (semi‐colon bug)
Soroush Dalili

7. Exploiting unexploitable XSS
Stephen Sclafani

8. Our Favorite XSS Filters and how to Attack them
Eduardo Vela (sirdarckcat), David Lindsay (thornmaker)

9. RFC1918 Caching Security Issues
Robert Hansen

10. DNS Rebinding (3-part series Persistent Cookies, Scraping & Spamming, and Session Fixation)
Robert Hansen

JSON Parameter Pollution

Bloggen Cat Slave Diary skriver kort om JSON Parameter Pollution. Jag berättade om HTTP parameter pollution i våras och tycker fortfarande det är en fascinerande säkerhetsbugg.

Genom att skicka in samma parameter två eller flera gånger i samma request så kan applikationen och servern luras att validera en parameter men använda en annan. I JSON-fallet ser det ut så här:

{"varName": value1, "varName": value2, "varName": value3}

Tydligen verkar de flesta JSON-ramverk använda det sista värdet, alltså value3 i exemplet. I kombination med egenutvecklad kod som kontrollerar det första värdet kan det bli farligt.

Burp Suite v1.3 släppt

Http/https-proxyn Burp Suite v1.3 finns nu tillgänglig för nedladdning. Ett uppskattat verktyg bland många av mina pentestarvänner (både gratis- och betalversionen).

Så här beskriver de sina nya features:

• A new message editor/viewer optimised for HTTP requests and responses, with colourised syntax, mouse-over decoding, and quick conversion functions.
• Facility to add comments and highlights to the proxy history and site map.
• Support for viewing and editing AMF-encoded messages.
• Improved handling of SSL server certificates, to eliminate browser SSL warnings and connection problems with thick clients.
• Copy to file / paste from file to facilitate working with binary content.
• New display filters.
• Greatly enhanced extensibility.
• Configurable DNS resolution, to override your computer's own resolution, facilitating work with non-proxy-aware clients.
• Fine-grained upstream proxy rules.
• Exporting of HTTP messages and metadata in XML format.

Alternativ? Ja, det finns OWASP WebScarab, OWASP WebScarab Next Generation (ej klar) och Paros Proxy. Kommentera gärna om det är något verktyg som borde vara med på listan eller om ni har någon åsikt om de fyra jag nämnt.

Säkerhet i Java EE 6, HttpServletRequest

Jag har kollat lite på HttpServletRequest-API:et i nya Java EE 6 och dess stöd för autentisering.

Fyra sorters autentisering

Man konfigurerar en autentiseringsmetod för sin servlet-kontext. Alla JEE 6-containers stödjer:

• Basic Authentication, BASIC_AUTH
• Formulärbaserad autentisering, FORM_AUTH
• Autentisering med klientcertifikat (2-vägs-SSL), CLIENT_CERT_AUTH

Digest Authentication, DIGEST_AUTH, anses fortfarande vara för ovanligt och behöver därför inte stödjas. Snacka om dödlig låsning. Digest Authentication har ju hela tiden varit tänkt som steget bort från Basic Authentication och är i grund och botten inloggning med saltad MD5-hash där klient och server väljer varsitt salt. Synd att det inte blev ett krav.

HttpServletRequest 3.0 innehåller tre nya säkerhetsmetoder: authenticate(), login() och logout(). Så här fungerar de:

Autenticate

boolean authenticate(HttpServletResponse response) throws IOException, ServletException

Kollar om användaren är autentiserad. Helt enkelt ett sätt att införa accesskontroll på sin servlet. Den returerar true om getUserPrincipal(), getRemoteUser(), och getAuthType() är satta, dvs inte returnerar null. Returnerar false om autentisering misslyckades och en felsida har skapats i response-objektet.

Kastar en ServletException om autentisering misslyckades och anroparen ska hantera felet.

Login

void login(String username, String password) throws ServletException

Inloggningsmetoden. Kontrollerar användarnamn och lösenord enligt den autentiseringsmetod som konfigurerats för containern. Om den här metoden returnerar (dvs inte kastar ett undantag) så måste värden vara satta så att getUserPrincipal(), getRemoteUser(), och getAuthType() inte returnerar null.

Kastar en ServletException om den konfigurerade autentiseringen inte accepterar användarnamn/lösenord (t ex klientcertifikat), om användaren redan är inloggad, eller om inloggningen misslyckades (t ex fel lösenord).

Logout
void logout() throws ServletException

Ser till att getUserPrincipal(), getRemoteUser(), och getAuthType()returnerar null. Kastar en ServletException om utloggningen misslyckades.

Sen finns förstås de gamla metoderna som stöd:

• String getAuthType()
• String getRemoteUser()
• boolean isUserInRole(String role)
• Principal getUserPrincipal()

(Inpirationen till att skriva om det här fick jag från Ramesh Nagappan på Sun som precis har bloggat om några av säkerhetsnyheterna i Java EE 6, bl a HttpServletRequest. Ramesh har en del intressant exempelkod i sitt blogginlägg.)

Mappning WASC Threats - OWASP Top 10

Jeremiah Grossman och Bil Corry har förtjänstfullt mappat WASC Threat Classification 2.0 till OWASP Top 10 rc1. Läs deras blogginlägg och tillhörande diskussion här.

Mappningen:

Stämning mot RockYou efter SQL injection

Jag bloggade för ett par dagar sen om 32 miljoner stulna konton hos RockYou.

I kölvattnet stämmer nu en av användarna RockYou. Det blir med största sannolikhet USAs första stämning rörande SQL injection och okrypterad lagring av lösenord utan att kreditkortsnummer är inblandade.

Om RockYou fälls ändras villkoren för mjukvarubranschen -- det är en allvarlig försummelse att missa två av tio på OWASP Top 10. Oavsett om man lyder under PCI-DSS eller inte.

"An Indiana resident has sued application developer RockYou for an alleged security breach that exposed 32 million users' email addresses and passwords and social networking log-ins.

- While some security threats are unavoidable in a rapidly developing technological environment, RockYou recklessly and knowingly failed to take even the most basic steps to protect its users."

Säkerhet i SharePoint/MOSS

OWASP har dragit igång ett SharePoint-initiativ. Till att börja med är det en sammanfattning av länktips från diskussioner på en av OWASP-listorna. Ta del av dem och bidra gärna själva!

OWASP: Research for SharePoint

Framtiden här ... för SpamAssassin

Antispamfiltret SpamAssassin har råkat ut för en 2010-bugg. Filtret var satt att spammarkera mejl som skickats "... grossly in the future". Det var bara det att framtiden hade hårdkodats och började 2010.

Regeln såg ut så här:

header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]

describe FH_DATE_PAST_20XX The date is grossly in the future.

Alla mejl som skickats 2010 och framåt får 3,4 "spampoäng" extra vilket kommer skicka en hel del legitim e-post ner i skräpkorgen. En fix har kommit men fram tills den är installerad så bör ni kolla om ni förlorat något (dvs om ni kör SpamAssassin).

Fixen i sig är lite rolig den med:

header FH_DATE_PAST_20XX Date =~ /20[2-9][0-9]/ [if-unset: 2006]

describe FH_DATE_PAST_20XX The date is grossly in the future.

Hoppas de kommer ihåg att fixa det ordentligt till 2020 nu bara :).

WASC Threat Classification v2.0

WASC (The Web Application Security Consortium) har precis släppt version 2.0 av sin hot-kategorisering: WASC Threat Classification. Det är ett bra referensmaterial för säkerhetsrapporter eller presentationer och innehåller beskrivningar och exempel på hot och attacker.

Här är den övergripande kategoriseringen:

Attacks	Weaknesses
Abuse of Functionality	Application Misconfiguration
Brute Force	Directory Indexing
Buffer Overflow	Improper Filesystem Permissions
Content Spoofing	Improper Input Handling
Credential/Session Prediction	Improper Output Handling
Cross-Site Scripting	Information Leakage
Cross-Site Request Forgery	Insecure Indexing
Denial of Service	Insufficient Anti-automation
Fingerprinting	Insufficient Authentication
Format String	Insufficient Authorization
HTTP Response Smuggling	Insufficient Password Recovery
HTTP Response Splitting	Insufficient Process Validation
HTTP Request Smuggling	Insufficient Session Expiration
HTTP Request Splitting	Insufficient Transport Layer Protection
Integer Overflows	Server Misconfiguration
LDAP Injection
Mail Command Injection
Null Byte Injection
OS Commanding
Path Traversal
Predictable Resource Location
Remote File Inclusion (RFI)
Routing Detour
Session Fixation
SOAP Array Abuse
SSI Injection
SQL Injection
URL Redirector Abuse
XPath Injection
XML Attribute Blowup
XML External Entities
XML Entity Expansion
XML Injection
XQuery Injection