AppSec Research 2010 Challenge 6

Utmaning sex är nu publicerad på konferenswikin. Den handlar om att designa en logga för konferensen. Första pris är en gratisbiljett till AppSec Research 2010. Ta chansen och visa på dina artistiska talanger!

Påverka nya OWASP Top 10

Jag gissar att ingen missat att nya OWASP Top 10 (release candidate) presenterades i fredags. Nu har vi i communityn fram till sista december på oss att komma med kommentarer. OWASP Top 10 är alltså listan som PCI refererar till och som idag utgör riktlinjer hos väldigt många utvecklingsorganisationer. Ta chansen att påverka den!

Onsdag 2/12 bjuder Omegapoint in till en diskussionskväll med lussefika.

Agenda

17.30 Välkomna, mingel

18.00 Genomgång OWASP Top 10 2010 rc1, fokus på det som är nytt (John Wilander)

18.40 Bensträckare

18.50 Diskussion (gemensam feedback skickas in till OWASP):

- Är det rätt hot och risker på listan? Är det det här vi ser hos kunder?

- Är listan i rätt ordning? Observera att den numer är riskbaserad.

- Är listan bra formulerad? Fungerar den som underlag för pentester och PCI-granskningar? Förstår kunderna?

- Hur når vi ut med listan? Listan i sig gör ju ingen glad. Kort sagt, hur gör vi världen bättre?

- Ska vi översätta den till svenska (förslagsvis två-och-två per punkt under dec-jan)?

Anmäl er genom att mejla john.wilander [at] owasp.org senast måndag 23/11 (begränsat antal platser)

Vi ses!

Microsoft dödar kodpolicy i .Net 4

Jag har skrivit tidigare om eländet med Javas Security Manager och att alla applikationsservrar stänger av den som default. Nu har Microsoft tagit samma beslut om sin Code Access Security. I .Net Framework 4 gäller:

"(...) all unhosted managed code runs as fully trusted by default."

och motiveringen får alla Javamänniskor att le igenkännande:

"While CAS policy was very powerful and allowed for very granular controls, it was extremely difficult to get right and could hinder more than help. (...) many people wondered why their applications suddenly stopped working"

Microsoft skriver om det och ersättningen i form av en säkerhetspolicy för en hel applikationsdomän där du delar upp dina applikationer i partial trust och full trust. Undrar just när Sun/Oracle ska göra något åt policy-problemen i Java?

Java Enterprise Rootkits

Allvarligt talat så vill jag inte skriva det här blogginlägget. Jeff Williams presentation om Java-rootkits fick mig nämligen att må dåligt. Om du inte riktigt har koll på vem som utvecklar dina applikationer (eller alla open source-bibliotek ni använder) så kommer du också må dåligt.

Vad kan en elak Javautvecklare åstadkomma på en vecka? Vad kan han/hon smyga in i koden? Det frågade sig Jeff och ägnade en vecka åt att göra rootkits i Java. De presenterar det i en 40-sidig rapport med tillhörande Eclipse-projekt (zip) men här kommer några godbitar.

Vad är ett rootkit?

Rootkits är gömda bakdörrar. Att bara göra en bakdörr i Java är inte svårt (servlet som lyssnar dina instruktioner). Att gömma dem är utmaningen.

Default: Ingen Security Manager

De flesta bakdörrar stoppas av en konfigurerad Security Manager. Men eftersom ingen kör med en Security Manager (avstängd som default i Tomcat, Websphere ...) så får all egenutvecklad kod göra vad som helst på maskinen. Alltså kommer rootkit-koden fungera bra i produktion.

Hur gömmer vi kod?

Det finns flera sätt att gömma sin bakdörr. Grundtricket är att göra data till bytekod i JVM:en. Så vi behöver bara kunna gömma data och några kodrader som omvandlar vår data till kod.

Lämpliga ställen för att gömma data är i en byte-array någonstans, i en åsidosatt toString()-metod som returnerar vår kod som en sträng, eller i databasen för att sen fiska upp den med SQL.

Skapa bytekod

För att skapa bytekod ur data så skriver vi ner den direkt på på class path:en och kör den, ungefär så här:

new File(getDirOnClasspath(), "Attack.class");

Class.forName("Attack").newInstance();

Vi kan också kompilera direkt i koden eftersom kompilatorn är tillgänglig i JDKn:

ToolProvider.getSystemJavaCompiler();

Om produktionssytemet körs på en JRE utan kompilator så finns alltid JSP-kompilatorn.

Eller så skapa vi en ny klassladdare (new ClassLoader()) åsidosätter defineClass() i den och skickar in vår Base64-kodade bytearray och den laddas och exekveras.

Lura kodgranskaren

Vi kan behöva lura kodgranskaren så han/hon inte förstår vad vi gör. Det görs bäst med förvillande kodkommentarer och genom att skriva svår kod med inspiration från javapuzzlers.com.

En riktigt elak grej är att skapa enhetstester som körs på byggservern och där injicerar skadlig kod. Vem kodgranskar enhetstesterna?

Andra slimmade bakdörrar

Som alternativ till data-till-bytekod så kan vi införa ett vanligt servletfilter som åsidosätter isUserInRole och kollar ifall en förvald parameter (typ 'backdoor') finns i requestet. Om den förvalda parametern finns så returnerar isUserInRole sant. Visst vi får lägga till det i web.xml men vem kommer hitta det?

I Servlet 3.0-API:et kan man dessutom lägga till och ta bort servlets och filter programmatiskt, dvs utan att ändra i web.xml.

Eller mygla in din skadliga jar i ext-katalogen så hamnar du direkt på classpath:en

Rootkits i open source

Tänk er nu att någon lägger en trojan i Log4J. Kanske inte ens i källkoden utan genom att ändra direkt i klassfilen/jaren som du laddar hem. Hur många skulle åka dit på den? Typ alla större Javasystem i världen.

Några andra mjukvaror som du kanske använder bygger på mycket öppen källkod:

• Hudson core innehåller 103 open source-projekt
• Maven core innehåller 15 open source-projekt
• Subversion innehåller 3 open source-projekt

Vad göra åt det?

Det som får mig att må dåligt över allt det här är att jag inte riktigt vet vad vi ska göra åt det. Jeff och Bruce Schneier har tillsammans skrivit ihop råd till den som är orolig:

• Begränsa antalet utvecklare
• Se till att du har pålitliga utvecklare
• Begränsa vilken kod du litar på (begränsa vilka api:er som får användas, t ex inte reflection)
• Begränsa beroenden under byggprocessen (kör vanliga javac istället för magiska saker som Maven när du bygger release)
• Begränsa antalet personer du är beroende av i produktion/drift
• Leta aktivt efter skadlig kod

Listan ovan får mig bara att tänka -- "Det kommer aldrig hända.". Så vi får väl lugnt vänta på de första avslöjandena om stora, hemska rootkits istället. :(

OWASP Top 10 2010 (rc1)

OWASPs välkända topp tio-lista kommer i en ny version 2010. Dave Wichers presenterar just nu rc1 av den. OWASP Top 10 2010 är riskbaserad, dvs graderad utifrån sannolikhet och konsekvens.

• A1 (A2) Injection
• A2 (A1) Cross-Site Scripting (XSS)
• A3 (A7) Broken Authentication and Session Management
• A4 (A4) Insecure Direct Object References
• A5 (A5) Cross-Site Request Forgery (CSRF)
• A6 (Ny) Security Misconfiguration (utvecklare använder ramverk men konfigurerar dem fel och sannolikheten att en attackerare hittar såna fel är större än att han/hon hittar applikationsspecifika fel)
• A7 (A10) Failure to Restrict URL Access
• A8 (Ny) Unvalidated Redirects and Forwards (destinationsadressen för en redirect eller en forward ligger i en parameter som klienten kan ändra, ganska vanligt och mycket farligt)
• A9 (A8) Insecure Cryptographic Storage
• A10 (A9) Insufficient Transport Layer Protection
• (Borttagen) A3 Malicious File Execution (mest ett php-problem)
• (Borttagen) A6 Information Leakage and Improper Error Handling (ej hög risk)

Planen är att låta communityn kommentera fram till sista december och sen fastställa det hela i början av 2010. Därför ska vi försöka ha en OWASP Sweden-kväll i december där vi diskuterar igenom listan och kommer med gemensam feedback.

[Uppdatering] Nu finns nya listan på wikin.

Säkra J2EE-mönster

Ett mycket intressant OWASP-projekt är OWASP Security Analysis of Core J2EE Design Patterns. Det handlar inte om säkerhetsmönster utan om säkra mönster. Helt enkelt -- hur man skriver säkra applikationer med de vanliga J2EE-mönstren.

Jag kan inte återge alltihop här utan hänvisar till wikin. Där går man igenom säkra mönster för presentationslagret, affärslogiken och informations-/persistenslagret.

Men som en liten aptitretare så kan jag nämna att Synchronization Token i Struts är ett utmärkt skydd mot Cross-Site Request Forgery (CSRF). Use it!

Pentesta WCF web services

Brian Holyfield gav en del konkreta tips för pentestning av WCF-webbtjänster.

Proxy för binär SOAP?

Windows Communication Foundation (WCF) har försökt göra något åt storleksexplosionen med SOAP genom att införa ett packat, binärt SOAP-format. Bra för prestanda, dåligt för pentestare.

Hur ska vi nu kunna fuzza eller pentesta våra web services? Microsoft har turligt nog publicerat formatet och some-guy-on-the-internet har implementerat en codec.

Brian gjorde plugins till Burp-proxyn men kunde bara antingen avkoda inkommande trafik eller koda utgående, inte både och. Så han fick utveckla två plugins och köra dubbla proxies, en på invägen och en på utvägen (med varsin port förstås). På det viset fick han möjlighet att titta på och manipulera SOAP:en.

Hitta WSDL:en

Pentestare gillar att hitta WSDL-filer för att snabbt se hur gränssnittet ser ut. Microsoft har å andra sidan bestämt sig för secure by default och publicerar in WSDL-filer som default. Men om du använder templates i Visual Studio så slås det på.

Ett alternativ är att anropa en så kallad MEX-tjänst som ofta publiceras i .Net-sammanhang och ger metadata om webbtjänsten. Det visar sig att den mest klär in WSDL:en med lite mex-taggar och är ett utmärkt sätt att få tag på WSDL:en.

Ytterligare ett alternativ finns om det rör sig om Silverlight enabled WCF services. Då kan du ladda hem klienten (.xap-fil), packa upp den (det är en zip) och om klienten är gjord i Visual Studio så har den skapat metodstubbar för alla ändpunkter i webbtjänsten, inte bara dem som klienten faktiskt anropar. Bara att rota igenom klasserna för att hitta information motsvarande WSDL:en med andra ord.

Ny applikationsbrandvägg: ESAPI WAF

ESAPI-gänget har utvecklat en riktigt intressant applikationsbrandvägg -- ESAPI WAF. TIll skilland från modsec som körs på Apache så är ESAPI WAF ett J2EE-filter i din web.xml.

Hur patcha mha EASPI WAF?

Vi går direkt på det intressanta -- hur fixar man säkerhetshål med hjälp av ESAPI WAF? Väl i drift handlar det bara om XML-konfiguration i en policyfil. Jämför det med att behöva branch:a koden, buggfixa, enhetstesta, bygga, systemtesta och driftsätta.

Två konfigurationsexempel ...

Indatavalidering av en request-parameter:

<virtual-patches>

<virtual-patch

id="bugtracker-id 1234"

path="/foo"

variable="request.parameters.bar"

pattern="[0-9a-zA-Z]"

message="detected and stopped attack XYZ"/>

</virtual-patches>

Utdatakodning, t ex sätta HTTPOnly i sina cookies (dock ej sessionscookies eftersom WAFen ligger i applikationslagret) eller lägga till headers (anti-clickjacking med X-FRAME-OPTIONS, UTF-8-kodning etc):

<outbound-rules>

<add-http-only-flag>

<cookie name="*" />

</add-http-only-flag>

<add-header>

...

</add-header>

</outbound-rules>

Hur konfigurera in ESAPI WAF?

Lägg till filter och filtermappning i web.xml (ca 15 rader). Sen en bunt jar:er (ESAPI plus beroenden) och DEBUG-konfiguration för Log4J. Det här kan du göra direkt i den uppackade war:en.

WAF-kritik

WAFar får rätteligen mycket kritik. Om man tror att en WAF ska fixa alla säkerhetsproblem så är man fel ute. Några vanliga invändningar och svar:

• "WAFar ökar attackytan." Felkonfigurerade -- ja. Men det kan man säga om i princip alla säkerhetsfunktioner som är exponerade.
• "WAFar ger kulturproblem i projekten." Ptja, ibland. Det är klart att det blir bråk med arkitekter, projektledare och andra när du drar in en WAF i projektet.
• "WAFar kan inte lösa problem i affärslogiken." Sant. Det är därför vi appsec-människor har jobb.
• "WAFar dyra." ESAPI WAF gratis :).
• "WAFar funkar inte i vårt nät." ESAPI WAF ligger i applikationlagret.

Säkra din Facebook

Tom Eston på Social Media Security nämnde i förbigående att de tagit fram en guide för att konfigurera säkerhet och personlig integritet i sin Facebook. Två sidor vettig information:

Facebook Privacy & Security Guide (pdf)

JSTL + XSS = sant

JSTL, JSP Standard Tag Library, är ett taggbibliotek för att dynamiskt skapa HTML via JSP-sidor utan att skriva inline Java. En vanlig tagg är c:out som injicerar ett värde i sidan. Till exempel:

<c:out value="${address}"/>

Default-kodningen av utdata från c:out är XML vilket innebär att injicerat JavaScript i address skulle få skript-taggen kodad med &lt och &gt. Alltså säker mot cross-site scripting (XSS) ... eller?

<script>

...

<c:out value="${address}"/>

...

</script>

Om du använder c:out inuti ett skript-block så behövs inga skript-taggar i det injicerade skriptet. Alltså går det att göra XSS via JSTL. Läbbigt.

SDLC på GE

General Electric (GE) finns inom sjuk- och hälsovård, infrastruktur, bank och mycket mer. De har en enorm mängd applikationer och kunder. För ett par år sedan beslutade man att införa en Security Development Lifecycle (SDLC) och Darren Challey har drivit projektet de senaste 2,5 åren.

Ändra kulturen

När Darren fick SDLC-jobbet så fick han en post-it-lapp av sin företrädare med orden Culture Change. Att införa SLDC handlar om att ändra kulturen kring mjukvaruutveckling. Och chefer förstår att kulturförändring är ett stort och svårt ingrepp.

Kommunikation avgörande

För att lyckas så måste du satsa på kommunikation. Identifiera nyckelpersoner (informella ledare, doers och de-med-budget) och se till att de är informerade.

AppSec-programmet på GE

På GE beslutade man sig tidigt för att fokusera på applikationssäkerheten hos externa mjukvaruleverantörer. På det viset kunde man jämföra dem och se vilka aktiviteter som betydde något.

Men det innebar också att det var tredjepartsleverantörer som faktiskt implementerade GEs SDLC, GE själva definierade vad leverantörerna skulle göra och vilka riktlinjer de skulle följa. Först vid acceptanstester så gör GE en ordentlig genomgång med säkerhetstester för att mäta kvaliteten på mjukvaran.

Alla tredjepartsleverantörer får skriva under på att arbeta med tre områden:

1. Riktlinjer

Man sätter upp en arbetsgrupp som träffas varannan vecka för att diskutera applikationssäkerhet. De är ansvariga för implementation av riktlinjer för säker kod, sårbarhetshantering, säker driftsättning och liknande.

2. Utbildning

GE erbjuder tre nivåer på utbildning och flervalsprov för utvecklare.

- Intro till applikationssäkerhet, 60 min

- Best practices för säker utveckling, 90 min

- Attackmönster & motmedel 120, min

- Flervalsprov på nätet med hundratals frågor. Utvecklarna förväntas ta provet regelbundet och får slumpmässiga frågor under en avgränsad tid, t ex en timme.

3. Verktyg

Darren höjde ett varnande finger för att fokusera för mycket och för tidigt på verktyg. GE utvärderade hur som helst de två bästa verktygen för statisk kodanalys och de två bästa verktygen för black-box-testning och kunde konstatera att verktygen hittade ca en tredjedel av de fel som manuella tester hittade.

Mät och publicera

Det är GE själva som genomför testerna och de publicerar sina leveratörers resultat i form av antal funna brister (hög, medel, låg). Det skapar en tävling mellan leverantörer och ger GEs inköpare något att pressa leverantörerna med. Efter att de har publicerat resultaten så blir Darren alltid uppringd och får höra allehanda ursäkter :). Men som han själv uttryckte det "What gets measured gets done".

GE Center of Excellence

GE har ett eget Center of Excellence (COE) med testare som granskar mjukvaruleveranser. Tillsammans med ett säkerhetsföretag har de tagit fram interna utbildningar för testare/granskare och har också ett internt karriärsprogram (junior till senior granskare i tre steg) vilket var viktigt för att få duktiga människor att satsa.

COE kan sen avropas internt inom GE och har fått goda omdömen av projekt och verksamheter. Deras granskningar gör skillnad.

Ser en förbättring

Men blir det bättre då? Ja, i snitt har antalet högrisk-sårbarheter per granskning gått ner substantiellt de senaste tre åren. Det blir bättre. Men man hamnar på platåer där utvecklingen står still ett halvår och för att få ner antalet säkerhetshål ytterligare så måste man vässa riktlinjer, utbilning och uppföljande granskning.

Ingen OWASP-certifiering

En större fråga som diskuterades nästan en timme under gårdagens Summit var om OWASP ska ge sig in i certifieringsbranschen, antingen med egna certifieringar eller med krav på tredjepartscertifieringar.

Egna certifieringar

Att köra egna certifieringar går inte eftersom OWASP bara har en heltidsanställd (Kate) och därmed inte en chans att sköta administration kring certifieringstillfällen, utbildning och så vidare. Och vi vill inte anställa fler.

Kravställa externa certifieringar

Att ställa krav på tredjepartscertifieringar är en burk mask som folk uttryckte det. De flesta som erbjuder certifieringar (ISC2, SANS ...) tjänar pengar på det. OWASP är inte intresserade av det. Så varför vill dessa tredjeparter att OWASP ska ge sig in i leken? Jo, för att de vill profitera på vårt varumärke. OWASP har byggt upp en stor trovärdighet som säkert går att exploatera.

Certifieringar = bråk

Certifieringar leder alltid till bråk och hån. Ta till exempel ASS-certifieringen. Varför ska vi i OWASP ge oss in i det getingboet och riskera vår trovärdighet? Det är helt enkelt inte värt det.

Öppna frågor ett måste

OWASP står dessutom för öppenhet i alla sammanhang. Det gör att certifieringsfrågorna hos tredje part skulle behöva vara öppna. Annars kan vi inte sätta en OWASP-stämpel på det. För att en certifiering med öppna frågor ska funka så behövs tusentals frågor med erforderlig förvaltning. Vem skulle gå med på det?

Slutsats

Diskussionen slutade (läs avbröts) med att styrelsen fick i uppdrag att formulera "a statement like the supreme court" som sa nej till certifieringar med en tydlig förklaring varför.

[Uppdatering]: Under nattliga samtal senare under konferensen så insåg jag att sista ordet säkerligen inte är sagt. Det finns starka krafter som vill se en OWASP-certifiering i någon form. De valde att vara tysta under diskussionen men kommer säkert samla sig och återkomma. T ex satt tydligen en representant för ISC2 med på Summit:en. Hon var enligt uppgift inte helt nöjd med den hårda diskussionen ...

Summering Summit

Med början 08.30 genom lunchen hela vägen till kl 17.30 har 50 personer diskuterat utvecklingen för OWASP.

Mitt allmänna intryck är att OWASP nu har blivit så stort att mer struktur behövs. Wikin är vildvuxen, det anordnas en bunt regionala konferenser och det är till och med lokalföreningar och projekt som har hunnit dö i det tysta.

Man utökar nu styrelsen till sju personer och under dem finns sex (snart sju) globala kommittéer som koordinerar OWASPs huvudområden:

• Projekt
• Medlemskap
• Utbildning
• Konferenser
• Industrikontakter
• Chapters
• (Ny: Nätverkande/relationer)

Respektive kommitté hade hand om ett pass under dagen.

Projekt: OWASP-projekt utvärderas nu dels enligt en releaseplan (alfa, beta, stable) och en hälsokontroll (löser projektet det problem som det ska, finns det någon nytta, används det?)

Medlemskap: OWASP har varit lite ambivalenta kring vad man ska få som medlem. Om allt är öppet och tillgängligt ändå, varför ska man betala? "För att stödja OWASP!" svarar vi. Men det funkar inte riktigt. Särskilt inte på företagsmedlemmar. Det verkar nu som om ett företagspaket kommer tas fram för de företag som blir medlemmar. Dessutom finns ett förslag på ett "pay once"-medlemskap vid sidan av det vanliga $5,000 per år.

Utbildning: OWASP vill få bättre kontakt med universitet runt om i världen. Vi diskuterade hur vi kan spela på deras planhalva och kom fram till att vi både kan ha akademiska personer i våra chapter boards och utgöra stöd i forskningsansökningar, t ex genom att vara en informationskanal (channel of dissemination).

Konferenser: Planeringen för 2010-års konferenser på gång. Stockholm har ju hand om nästa globala konferens så där ligger vi långt fram. Minnesota och Los Angeles har ansökt om att ha den amerikanska konferensen om ett år. Det finns två nivåer till och det är regionala/nationella konferenser och endags-event. Där är det helt öppet för förslag. Alla har rätt att anordna sådana.

Industrikontakter: Flera lyfte frågan om att ha ett industriellt advisory board, dvs ett ledningsråd med näringslivsrepresentanter som kommer med feedback på vad OWASP gör och borde göra för att stötta deras utvecklingen av säkra applikationer.

Chapters: Under nästa år ska man göra en ordentlig inventering av vilka chapters som behöver upplivas. En enkät visade att chapter leaders tyckte det största problemet var att hitta bra talare till sina möten. Det finns pengar till att bjuda in talare i projektet OWASP on the move men väldigt få nyttjar det. Man ska göra ett omtag för att få fler chapters att använda pengarna. Därtill kommer mer och mer pengar via medlemsavgifter eftersom en viss procent alltid går till det lokala chaptret.

Val till OWASP-styrelsen idag

Senare idag (ikväll svensk tid) röstar världens OWASP-medlemmar om två nya styrelsemedlemmar. Fyra personer kandiderar:

• Pravir Chandra (CLASP, OpenSAMM)
• Kuai Hinojosa (Chapter leader Minneapolis)
• Eoin Keary (Chapter leader Ireland, Testing Guide, Code Review Guide)
• Matt Tesauro (LiveCD, Global Projects Committee)

Pravir, Eoin och Matt är på plats medan Kuai deltar på mobil-som-hålls-mot-mikrofon, dvs hörs inte. De tre jag hör poängterar vikten av att OWASP behöver utveckla sitt samarbete med näringslivet. Flera nämner möjligheten att sätta samman ett advisory board med näringslivsrepresentanter, exempelvis från nuvarande OWASP-sponsorer.

Det är också mycket diskussion om hur vi får OWASP att växa och hur vi motiverar personer och företag att bli betalande medlemmar.

Om du är medlem -- läs om kandidaterna och rösta.

På plats i Washington DC

Klockan 09.30 tisdag förmiddag köpte jag en biljett till Arlanda express. Klockan 02.30 onsdag natt klev jag in på hotellrummet i Washington DC. Det är dags för årets upplaga av OWASP AppSec i USA!

3 på natten (svensk tid) i ett hotellrum. Jag hade två val. Antingen sova (kändes väldigt aktuellt) eller leta efter OWASP-folket. Vis från tidigare konferenser så valde jag det senare. När man väl har börjat känna en community så finns det inget så givande som sociala träffar utanför programmet.

Jag hittade dem till slut i sportbaren, ca 20 personer varav jag kände hälften sen tidigare. Två öl senare har en av mina idéer blivit ett globalt förslag.

Under konferensen här i Washington kommer nämligen en draft för OWASP Top Ten 2010 presenteras. Sen ska den igenom två granskningsvändor innan den slutligen spikas. Min idé var att vi i OWASP Sweden ordnar en halv eller till och med en hel seminariekväll kring den nya topplistan och gemensamt ger vår feedback inför slutversionen. Tom Brennan i OWASPs styrelse gillade idén så mycket att han nu föreslagit att alla världens OWASP-chapter gör detsamma.

Under de närmsta tre dagarna kommer jag blogga från OWASP Summit och OWASP AppSec DC. Håll utkik.

Men nu blir det sova. Klockan är snart 6 svensk tid :/.

ESAPI Python Edition

Idag släpptes Python-versionen av ESAPI, Enterprise Security API. Ett öppet bibliotek med säkerhetsfunktioner för indatavalidering, utdatakodning, autentisering och så vidare.

ESAPI finns sen tidigare för Java EE, .Net och är på gång till PHP, klassisk ASP och ... Haskell!