Webservice (WS) -beveiligingstutorial met SOAP-voorbeeld

Wat is WS-beveiliging?

WS Security is een standaard die zich richt op beveiliging wanneer gegevens worden uitgewisseld als onderdeel van een webservice. Dit is een belangrijke functie in SOAP die het erg populair maakt voor het maken van webservices.

Beveiliging is een belangrijke functie in elke webapplicatie. Aangezien bijna alle webapplicaties worden blootgesteld aan internet, is er altijd een kans op een beveiligingsrisico voor webapplicaties. Daarom wordt het bij het ontwikkelen van webgebaseerde applicaties altijd aanbevolen om ervoor te zorgen dat de applicatie is ontworpen en ontwikkeld met het oog op beveiliging.

In deze tutorial leer je-

Veiligheidsbedreigingen en tegenmaatregelen
Beveiligingsnormen voor webservices
Hoe veilige webservices te bouwen
Best practices voor webservicebeveiliging

Veiligheidsbedreigingen en tegenmaatregelen

Om beveiligingsbedreigingen te begrijpen die vijandig kunnen zijn voor een webtoepassing, laten we eens kijken naar een eenvoudig scenario van een webtoepassing en kijken hoe het werkt in termen van beveiliging.

Een van de beveiligingsmaatregelen die beschikbaar zijn voor HTTP is het HTTPS-protocol. HTTPS is de veilige manier van communicatie tussen de client en de server via internet. HTTPS maakt gebruik van de Secure Sockets-laag of SSL voor veilige communicatie. Zowel de client als de server hebben een digitaal certificaat om zichzelf als echt te identificeren wanneer er communicatie plaatsvindt tussen de client en de server.

Bij een standaard HTTPS-communicatie tussen de client en de server vinden de volgende stappen plaats

De client stuurt een verzoek naar de server via het clientcertificaat. Wanneer de server het clientcertificaat ziet, maakt hij een aantekening in zijn cachesysteem, zodat hij weet dat het antwoord alleen naar deze client moet terugkeren.
De server authenticeert zichzelf vervolgens bij de client door zijn certificaat te verzenden. Dit zorgt ervoor dat de klant communiceert met de juiste server.
Alle communicatie daarna tussen de client en de server is versleuteld. Dit zorgt ervoor dat als andere gebruikers proberen de beveiliging te doorbreken en de vereiste gegevens te krijgen, ze deze niet kunnen lezen omdat ze worden gecodeerd.

Maar het bovenstaande type beveiliging werkt niet in alle situaties. Er kan een tijd komen dat de client met meerdere servers kan praten. Een voorbeeld hieronder toont een client die tegelijkertijd met zowel een database als een webserver praat. In dergelijke gevallen kan niet alle informatie via het https-protocol passeren.

Dit is waar SOAP in actie komt om dergelijke obstakels te overwinnen door de WS Security-specificatie op zijn plaats te hebben. Met deze specificatie worden alle beveiligingsgerelateerde gegevens gedefinieerd in het SOAP-headerelement.

Het header-element kan de onderstaande informatie bevatten

Als het bericht in de SOAP-tekst is ondertekend met een beveiligingssleutel, kan die sleutel worden gedefinieerd in het header-element.
Als een element in de SOAP-body is versleuteld, bevat de header de benodigde encryptiesleutels zodat het bericht kan worden ontsleuteld wanneer het de bestemming bereikt.

In omgevingen met meerdere servers helpt de bovenstaande techniek van SOAP-authenticatie op de volgende manier.

Omdat de SOAP-body is gecodeerd, kan deze alleen worden gedecodeerd door de webserver die de webservice host. Dit komt door hoe het SOAP-protocol is ontworpen.
Stel dat als het bericht wordt doorgegeven aan de databaseserver in een HTTP-verzoek, het niet kan worden gedecodeerd omdat de database niet over de juiste mechanismen beschikt om dit te doen.
Alleen wanneer het verzoek de webserver daadwerkelijk bereikt als een SOAP-protocol, kan het het bericht ontcijferen en het juiste antwoord terugsturen naar de client.

We zullen in de volgende onderwerpen zien hoe de WS Security-standaard kan worden gebruikt voor SOAP.

Beveiligingsnormen voor webservices

Zoals besproken in de eerdere sectie, draait de WS-Security-standaard om het hebben van de beveiligingsdefinitie in de SOAP-header.

De inloggegevens in de SOAP-header worden op 2 manieren beheerd.

Ten eerste definieert het een speciaal element genaamd UsernameToken. Dit wordt gebruikt om de gebruikersnaam en het wachtwoord door te geven aan de webservice.

De andere manier is om een binair token te gebruiken via het BinarySecurityToken. Dit wordt gebruikt in situaties waarin versleutelingstechnieken zoals Kerberos of X.509 worden gebruikt.

Het onderstaande diagram toont de stroom van hoe het beveiligingsmodel werkt in WS Security

Hieronder staan de stappen die plaatsvinden in de bovenstaande workflow

Er kan een verzoek worden verzonden van de webserviceclient naar Security Token Service. Deze service kan een tussenliggende webservice zijn die specifiek is gebouwd om gebruikersnamen / wachtwoorden of certificaten te leveren aan de daadwerkelijke SOAP-webservice.
Het beveiligingstoken wordt vervolgens doorgegeven aan de webserviceclient.
De webserviceclient heeft vervolgens de webservice gebeld, maar deze keer ervoor gezorgd dat het beveiligingstoken is ingesloten in het SOAP-bericht.
De webservice begrijpt dan het SOAP-bericht met het authenticatietoken en kan vervolgens contact opnemen met de Security Token-service om te zien of het beveiligingstoken authentiek is of niet.

Het onderstaande fragment toont het formaat van het authenticatiegedeelte dat deel uitmaakt van het WSDL-document. Nu gebaseerd op het onderstaande fragment, zal het SOAP-bericht 2 extra elementen bevatten, de ene is de gebruikersnaam en de andere is het wachtwoord.

Wanneer het SOAP-bericht daadwerkelijk wordt doorgegeven tussen de clients en de server, kan het deel van het bericht dat de gebruikersreferenties bevat eruit zien als hierboven weergegeven. De naam van het wsse-element is een speciaal element met de naam gedefinieerd voor SOAP en betekent dat het op beveiliging gebaseerde informatie bevat.

Hoe veilige webservices te bouwen

Laten we nu eens kijken naar het beveiligingsvoorbeeld van SOAP-webservices. We zullen een webservicebeveiliging bouwen op basis van het voorbeeld dat eerder in het SOAP-hoofdstuk is gedemonstreerd en zullen er een beveiligingslaag aan toevoegen.

In ons voorbeeld gaan we een eenvoudige webservice maken, die zal worden gebruikt om een string terug te sturen naar de applicatie die de webservice aanroept. Maar deze keer, wanneer de webservice wordt aangeroepen, moeten de inloggegevens aan de belservice worden verstrekt. Laten we de onderstaande stappen volgen om onze SOAP-webservice te maken en de beveiligingsdefinitie eraan toe te voegen.

Stap 1) De eerste stap is het maken van een lege Asp.Net-webtoepassing. Klik vanuit Visual Studio 2013 op de menuoptie Bestand-> Nieuw project.

Zodra u op de optie Nieuw project klikt, geeft Visual Studio u een ander dialoogvenster om het type project te kiezen en om de nodige details van het project te geven. Dit wordt uitgelegd in de volgende stap

Stap 2) In deze stap,

Zorg ervoor dat u eerst de C # -websjabloon voor ASP.NET-webtoepassing kiest. Het project moet van dit type zijn om een webservicesproject te kunnen maken. Door deze optie te kiezen, voert Visual Studio vervolgens de nodige stappen uit om de vereiste bestanden toe te voegen die vereist zijn voor elke webgebaseerde toepassing.
Geef een naam voor uw project die in ons geval is gegeven als " webservice.asmx. " Zorg er dan voor dat u een locatie opgeeft waar de projectbestanden worden opgeslagen.

Als u klaar bent, ziet u het projectbestand dat is gemaakt in uw oplossingsverkenner in Visual Studio 2013.

Stap 3) In deze stap,

We gaan een webservicebestand toevoegen aan ons project

Klik eerst met de rechtermuisknop op het projectbestand, zoals hieronder weergegeven

Zodra u met de rechtermuisknop op het projectbestand klikt, heeft u de kans om de optie "Toevoegen-> Webservice (ASMX) te kiezen om een webservicebestand toe te voegen. Geef gewoon de naam van Tutorial Service op voor het webservicenaambestand.

De bovenstaande stap zal een dialoogvenster openen waarin men de naam van het webservicebestand kan invoeren. Voer dus in het onderstaande dialoogvenster de naam van TutorialService in als de bestandsnaam.

Stap 4) Voeg de volgende code toe aan uw Tutorial Service asmx-bestand. Het onderstaande codefragment wordt gebruikt om een aangepaste klasse toe te voegen die zal worden gebruikt om de SOAP-koptekst te wijzigen wanneer het SOAP-bericht wordt gegenereerd. Aangezien we nu beveiligingsreferenties willen toevoegen aan de SOAP-header, is deze stap vereist.

return "This is a Guru99 Web Service";}public class AuthHeader : SoapHeader{public string UserName;public string Password;}}

Code Verklaring: -

We maken nu een aparte klasse met de naam AuthHeader, die van het type SoapHeader-klasse is . Telkens wanneer u wilt wijzigen wat er in de SOAP-header wordt doorgegeven, moet u een klasse maken die de ingebouwde SoapHeader-klasse van .Net gebruikt. Door de SOAPheader aan te passen, hebben we nu de mogelijkheid om een 'gebruikersnaam' en 'wachtwoord' door te geven wanneer de webservice wordt aangeroepen.
Vervolgens definiëren we variabelen van 'Gebruikersnaam' en 'Wachtwoord' die van het type tekenreeks zijn. Ze worden gebruikt om de waarden van de gebruikersnaam en het wachtwoord vast te houden die aan de webservice worden doorgegeven.

Stap 5) Als volgende stap moet de volgende code worden toegevoegd aan hetzelfde TutorialService.asmx-bestand . Deze code definieert eigenlijk de functie van onze webservice. Deze functie retourneert een string "Dit is een Guru99-webservice" naar de client. Maar deze keer wordt de tekenreeks alleen geretourneerd als de clienttoepassing de inloggegevens doorgeeft aan de webservice.

public class TutorialService : System.Web.Services.WebService{public AuthHeader Credentials;[SoapHeader("Credentials")][WebMethod]public string Guru99WebService(){if (Credentials.UserName.ToLower() != "Guru99" ||Credentials.Password.ToLower() != "Guru99Password"){throw new SoapException("Unauthorized",SoapException.ClientFaultCode);}eisereturn "This is a Guru99 Web service";}

Code Verklaring: -

Hier maken we een object van de AuthHeader-klasse die in de vorige stap is gemaakt. Dit object wordt doorgegeven aan onze Guru99Webservice waar de gebruikersnaam en het wachtwoord nauwkeurig kunnen worden bekeken.
Het [SoapHeader] -attribuut wordt nu gebruikt om aan te geven dat wanneer de webservice wordt aangeroepen, de gebruikersnaam en het wachtwoord moeten worden doorgegeven.
In dit codeblok onderzoeken we feitelijk de gebruikersnaam en het wachtwoord die zijn doorgegeven wanneer de webservice wordt aangeroepen. Als de gebruikersnaam gelijk is aan "Guru99" en het wachtwoord is gelijk aan "Guru99Password", dan wordt het bericht "This is a Guru99 Web service" doorgegeven aan de client. Anders wordt er een foutbericht naar de client gestuurd als het verkeerde gebruikers-ID en wachtwoord worden doorgegeven.

Als de code met succes is uitgevoerd, wordt de volgende uitvoer weergegeven wanneer u uw code in de browser uitvoert.

Uitgang:

De bovenstaande uitvoer wordt getoond wanneer het programma wordt uitgevoerd, wat betekent dat de webservice nu beschikbaar is. Laten we op de link Servicebeschrijving klikken.

Aan de hand van de servicebeschrijving kunt u nu zien dat de gebruikersnaam en het wachtwoord elementen zijn van het WSDL-bestand. Deze parameters moeten worden verzonden wanneer de webservice wordt aangeroepen.

Best practices voor webservicebeveiliging

Hieronder volgen de beveiligingsoverwegingen waarmee u rekening moet houden bij het werken met webservices

Controle en logboekbeheer - Gebruik logboekregistratie van toepassingen om alle verzoeken te loggen die naar de webservices komen. Dit geeft een gedetailleerd rapport over wie de webservice heeft aangeroepen en kan helpen bij impactanalyse als er een inbreuk op de beveiliging plaatsvindt.
Stroom van oproepen naar de webservice - Probeer de stroom van de oproepen in webservices te noteren. Standaard kan een toepassing meerdere webserviceverzoeken aanroepen met verificatietokens die tussen deze webservices worden doorgegeven. Alle oproepen tussen webservices moeten worden gecontroleerd en geregistreerd.
Gevoelige informatie - Neem geen gevoelige informatie op in uw logboekvermeldingen, zoals wachtwoorden of creditcardnummers of enige andere vertrouwelijke informatie. Als er een gebeurtenis is die deze informatie bevat, moet deze worden verwijderd voordat u zich aanmeldt.
Volg bedrijfsactiviteiten - Houd belangrijke bedrijfsactiviteiten bij. Instrumenteer bijvoorbeeld uw applicatie om de toegang tot bijzonder gevoelige methoden en bedrijfslogica vast te leggen. Laten we een voorbeeld nemen van een online winkelapplicatie. Er zijn meerdere stappen in een typische toepassing, zoals het kiezen van de te kopen items, de items die in de winkelwagen zijn geladen en vervolgens de uiteindelijke aankoop. Deze hele zakelijke workflow moet worden gevolgd door de webservice.
Juiste authenticatie - Authenticatie is het mechanisme waarmee de clients hun identiteit met de webservice kunnen vaststellen met behulp van een bepaalde set inloggegevens die die identiteit kunnen bewijzen. Men mag nooit de gebruikersreferenties opslaan, en daarom, als WS Security wordt gebruikt om de webservice aan te roepen, moet worden opgemerkt dat de webservice de inloggegevens die in de SOAP-header worden verzonden, niet opslaat. Deze moeten door de webservice worden weggegooid.

Overzicht

SOAP biedt een extra laag, WS Security genaamd, voor het bieden van extra beveiliging bij oproepen naar webservices.
De WS Security kan worden aangeroepen met een eenvoudige gebruikersnaam of wachtwoord of kan worden gebruikt met binaire certificaten voor authenticatie
We hebben gezien dat we in .Net de webservice zo kunnen aanpassen dat een gebruikersnaam en wachtwoord worden doorgegeven als onderdeel van het SOAP-headerelement.