Web Service(WS) beveiligingshandleiding met SOAP-voorbeeld

Wat is WS-beveiliging?

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

Beveiliging is een belangrijk kenmerk van elke webapplicatie. Omdat bijna alle webapplicaties worden blootgesteld aan internet, bestaat 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 wordt ontworpen en ontwikkeld met het oog op veiligheid.

Beveiligingsbedreigingen en tegenmaatregelen

Om beveiligingsbedreigingen te begrijpen die vijandig kunnen zijn voor een webapplicatie, kijken we naar een eenvoudig scenario van een webapplicatie en zien hoe deze werkt op het gebied 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 via het clientcertificaat een verzoek naar de server. Wanneer de server het clientcertificaat ziet, maakt hij een notitie in zijn cachesysteem, zodat hij weet dat het antwoord alleen naar deze client terug mag gaan.
De server authenticeert zichzelf vervolgens bij de client door het certificaat te verzenden. Dit zorgt ervoor dat de client met de juiste server communiceert.
Alle communicatie daarna tussen de client en de server is gecodeerd. Dit zorgt ervoor dat als andere gebruikers proberen de beveiliging te doorbreken en de vereiste gegevens te bemachtigen, zij deze niet kunnen lezen omdat deze gecodeerd zijn.

Maar het bovenstaande type beveiliging zal niet in alle situaties werken. Er kan een moment 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 het https-protocol passeren.

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

Het header-element kan de hieronder genoemde informatie bevatten

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

In omgevingen met meerdere servers is de bovenstaande SOAP-authenticatietechniek op de volgende manier nuttig.

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

In de volgende onderwerpen zullen we zien waarvoor de WS Security-standaard kan worden gebruikt SOAP.

Beveiligingsnormen voor webservices

Zoals besproken in de eerdere sectie draait het bij de WS-Security-standaard om het opnemen 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 Binary Token te gebruiken via de BinarySecurityToken. Dit wordt gebruikt in situaties waarin encryptietechnieken zoals Kerberos of X.509 worden gebruikt.

Het onderstaande diagram toont de manier waarop het beveiligingsmodel werkt in WS Security

Hieronder staan de stappen die plaatsvinden in de bovenstaande workflow

Er kan een aanvraag worden verzonden vanaf de webserviceclient naar Security Token Service. Deze service kan een tussenliggende webservice zijn die specifiek is gebouwd om gebruikersnamen/wachtwoorden of certificaten aan de daadwerkelijke SOAP-webservice te leveren.
Het beveiligingstoken wordt vervolgens doorgegeven aan de webserviceclient.
De webserviceclient riep vervolgens de webservice op, maar zorgde er deze keer voor dat het beveiligingstoken in het SOAP-bericht werd ingebed.
De webservice begrijpt vervolgens 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. Op basis van het onderstaande fragment zal het SOAP-bericht twee extra elementen bevatten, waarvan het ene de gebruikersnaam en het andere het wachtwoord is.

<xs:element name="UsernameToken">  
	<xs:complexType>       
		<xs:sequence>           
			<xs:element ref="Username"/>         
			<xs:element ref="Password" minOccurs="0"/>        
		</xs:sequence>       
	<xs:attribute name="Id" type="xs:ID"/>    
</xs:complexType></xs:element>

Wanneer het SOAP-bericht daadwerkelijk wordt doorgegeven tussen de clients en de server, kan het deel van het bericht dat de gebruikersgegevens bevat er uitzien zoals hierboven weergegeven. De wsse-elementnaam 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 een SOAP-webservice. We zullen een webservicebeveiliging bouwen op basis van het voorbeeld dat eerder in het SOAP-hoofdstuk werd gedemonstreerd en er een beveiligingslaag aan toevoegen.

In ons voorbeeld gaan we een eenvoudige webservice maken, die wordt gebruikt om een string terug te sturen naar de applicatie die de webservice aanroept. Maar deze keer moeten, wanneer de webservice wordt aangeroepen, de inloggegevens aan de bellende service 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 leeg bestand Asp.Net Webapplicatie. Klik in 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 de benodigde details van het project te geven. Dit wordt in de volgende stap uitgelegd

Stap 2) In deze stap,

Zorg ervoor dat u eerst de C# websjabloon voor ASP.NET-webtoepassing. Het project moet van dit type zijn om een webservicesproject te kunnen maken. Door deze optie te kiezen, voert Visual Studio de benodigde stappen uit om vereiste bestanden toe te voegen die vereist zijn door een 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.

Zodra u klaar bent, ziet u het projectbestand dat is gemaakt in uw Solution Explorer in Visual Studio 2013.

Stap 3) In deze stap,

We gaan een webservicebestand aan ons project toevoegen

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

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

De bovenstaande stap zal een dialoogvenster openen, waarin u de naam van het webservicebestand kunt invoeren. Voer in het onderstaande dialoogvenster de naam van TutorialService in als 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 wordt gebruikt om de SOAP-header te wijzigen wanneer het SOAP-bericht wordt gegenereerd. Omdat we nu beveiligingsreferenties aan de SOAP-header willen toevoegen, is deze stap vereist.

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

	}
}

Code-uitleg: -

We maken nu een aparte klasse genaamd AuthHeader die van type is SoapHeader-klasse. 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 string zijn. Ze worden gebruikt om de waarden van de gebruikersnaam en het wachtwoord op te slaan die aan de webservice worden doorgegeven.

Stap 5) Als volgende stap moet de volgende code aan hetzelfde worden toegevoegd TutorialService.asmx-bestand. Deze code definieert feitelijk 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);
		}
		eise
		return "This is a Guru99 Web service";
	}

Code-uitleg: -

Hier maken we een object van de klasse AuthHeader dat in de eerdere stap is gemaakt. Dit object wordt doorgegeven aan onze Guru99Webservice waarin de gebruikersnaam en het wachtwoord nauwkeurig kunnen worden onderzocht.
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 worden doorgegeven wanneer de webservice wordt aangeroepen. Als de gebruikersnaam gelijk is aan “Guru99” en het wachtwoord gelijk is aan “Guru99Password” dan wordt het bericht “Dit is een Guru99-webservice” doorgegeven aan de klant. Anders wordt er een foutmelding naar de client gestuurd als de verkeerde gebruikersnaam en het verkeerde wachtwoord worden doorgegeven.

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

Output:

De bovenstaande uitvoer wordt weergegeven wanneer het programma wordt uitgevoerd, wat betekent dat de webservice nu beschikbaar is. Laten we op de service klikken Descriptionen koppeling.

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

Best practices voor webservicebeveiliging

Hieronder staan de beveiligingsoverwegingen waar u rekening mee moet houden bij het werken met webservices

1. Auditing en logbeheer – Gebruik applicatielogboekregistratie om alle verzoeken die naar de webservices komen, te loggen. Dit geeft een gedetailleerd rapport over wie de webservice heeft aangeroepen en kan helpen bij de impactanalyse als er een beveiligingslek optreedt.

2. Stroom van oproepen naar de webservice – Probeer de stroom van de oproepen in webservices te noteren. Standaard kan een toepassing meerdere webservicesverzoeken aanroepen waarbij authenticatietokens tussen deze webservices worden doorgegeven. Alle gesprekken tussen webservices moeten worden gemonitord en geregistreerd.

3. Gevoelige informatie – Neem geen gevoelige informatie op in uw log-items, zoals wachtwoorden of creditcardnummers of andere vertrouwelijke informatie. Als er een gebeurtenis is die deze informatie bevat, moet deze worden verwijderd voordat u gaat loggen.

4. Houd zaken bij Operaties – Volg belangrijke bedrijfsactiviteiten. Instrumenteer bijvoorbeeld uw applicatie om toegang tot bijzonder gevoelige methoden en bedrijfslogica vast te leggen. Laten we een voorbeeld nemen van een online shoppingapplicatie. Er zijn meerdere stappen in een typische applicatie, zoals het kiezen van de te kopen items, de items die in het winkelwagentje worden geladen en vervolgens de uiteindelijke aankoop. Deze hele bedrijfsworkflow moet worden gevolgd door de webservice.

5. Juiste authenticatie – Authenticatie is het mechanisme waarmee de clients hun identiteit bij de webservice kunnen vaststellen met behulp van een bepaalde set inloggegevens die die identiteit kunnen bewijzen. U mag nooit de gebruikersgegevens opslaan. Als WS Security wordt gebruikt om de webservice aan te roepen, moet u er rekening mee houden dat de webservice de gegevens die in de SOAP-header worden verzonden, niet mag opslaan. Deze moeten door de webservice worden verwijderd.

Samenvatting

SOAP biedt een extra laag, WS Security genaamd, die extra beveiliging biedt wanneer er oproepen worden gedaan naar webservices.
De WS Security kan worden opgeroepen met een eenvoudige gebruikersnaam of wachtwoord of kan worden gebruikt met binaire certificaten voor authenticatie
Dat hebben we gezien bij . Net we kunnen de webservice aanpassen zodat een gebruikersnaam en wachtwoord worden doorgegeven als onderdeel van het SOAP-headerelement.

Je houdt misschien van: