streamalism.org

Ik heb zojuist het nieuwe aangekondigd Leer de lente natuurlijk, gericht op de basisprincipes van Spring 5 en Spring Boot 2:

1. Overzicht

In deze tutorial zullen we de ingebouwde beveiligingsinfrastructuur van Java bekijken, die standaard is uitgeschakeld. In het bijzonder zullen we de belangrijkste componenten, uitbreidingspunten en configuraties onderzoeken.

2. Beveiligingsmanager in actie

Het is misschien een verrassing, maar standaard Beveiligingsmanager instellingen zijn niet toegestaanveel standaardbewerkingen:

System.setSecurityManager (nieuwe SecurityManager ()); nieuwe URL ("// www.google.com"). openConnection (). connect ();

Hier schakelen we beveiligingstoezicht programmatisch in met standaardinstellingen en proberen we verbinding te maken met google.com.

Dan krijgen we de volgende uitzondering:

java.security.AccessControlException: toegang geweigerd ("java.net.SocketPermission" "www.google.com:80" "verbinden, oplossen")

Er zijn tal van andere use-cases in de standaardbibliotheek - bijvoorbeeld het lezen van systeemeigenschappen, het lezen van omgevingsvariabelen, het openen van een bestand, reflectie en het wijzigen van de landinstelling, om er maar een paar te noemen.

3. Gebruiksscenario

Deze beveiligingsinfrastructuur is beschikbaar sinds Java 1.0. Dit was een tijd waarin applets - Java-applicaties ingebed in de browser - vrij algemeen waren. Het was natuurlijk nodig om hun toegang tot systeembronnen te beperken.

Tegenwoordig zijn applets verouderd. Echter, Beveiligingshandhaving is nog steeds een actueel concept wanneer er een situatie is waarin code van derden wordt uitgevoerd in een beschermde omgeving.

Bedenk bijvoorbeeld dat we een Tomcat-instantie hebben waar clients van derden hun webtoepassingen kunnen hosten. We willen hen niet toestaan ​​om bewerkingen uit te voeren zoals System.exit () omdat dat andere applicaties zou beïnvloeden en mogelijk de hele omgeving.

4. Ontwerp

4.1. Beveiligingsmanager

Een van de belangrijkste componenten in de ingebouwde beveiligingsinfrastructuur is java.lang SecurityManager. Het heeft er meerdere checkXxx methoden zoals checkConnect, waarmee onze poging om verbinding te maken met Google in de bovenstaande test werd geautoriseerd. Ze zijn allemaal afgevaardigden naar de checkPermission (java.security.Permission) methode.

4.2. Toestemming

java.security.Permission instanties staan ​​voor autorisatieverzoeken. Standaard JDK-klassen maken ze aan voor alle potentieel gevaarlijke bewerkingen (zoals lezen / schrijven van een bestand, openen van een socket, enz.) En geven ze over aan Beveiligingsmanager voor de juiste autorisatie.

4.3. Configuratie

We definiëren machtigingen in een speciaal beleidsformaat. Deze machtigingen hebben de vorm van verlenen inzendingen:

verleen codeBase "file: $ {{java.ext.dirs}} / *" {toestemming java.security.AllPermission; };

De codeBase bovenstaande regel is optioneel. We kunnen daar helemaal geen veld specificeren of gebruiken getekend door (geïntegreerd met bijbehorende certificaten in de keystore) of opdrachtgever (java.security.Principal bevestigd aan de huidige thread via javax.security.auth.Subject). We kunnen elke combinatie van deze regels gebruiken.

Standaard laadt de JVM het algemene systeembeleidbestand dat zich bevindt op <java.home> /lib/security/java.policy. Als we een gebruikers-lokaal beleid hebben gedefinieerd in /.java.policy, de JVM voegt het toe aan het systeembeleid.

Het is ook mogelijk om een ​​beleidsbestand op te geven via de opdrachtregel: -Djava.security.policy = / mijn / policy-bestand. Op die manier kunnen we beleid toevoegen aan het eerder geladen systeem- en gebruikersbeleid.

Er is een speciale syntaxis voor het vervangen van alle systeem- en gebruikersbeleid (indien aanwezig) - dubbel is gelijk-teken: -Djava.security.policy == / mijn / policy-bestand

5. Voorbeeld

Laten we een aangepaste toestemming definiëren:

public class CustomPermission breidt BasicPermission uit {public CustomPermission (String naam) {super (naam); } openbare CustomPermission (String naam, String acties) {super (naam, acties); }}

en een gedeelde dienst die moet worden beschermd:

openbare class Service {public static final String OPERATION = "my-operation"; openbare ongeldige operatie () {SecurityManager securityManager = System.getSecurityManager (); if (securityManager! = null) {securityManager.checkPermission (nieuwe CustomPermission (OPERATION)); } System.out.println ("Bewerking wordt uitgevoerd"); }}

Als we het proberen uit te voeren terwijl een beveiligingsmanager is ingeschakeld, wordt er een uitzondering gegenereerd:

java.security.AccessControlException: toegang geweigerd ("com.baeldung.security.manager.CustomPermission" "mijn-operatie") op java.security.AccessControlContext.checkPermission (AccessControlContext.java:472) op java.security.AccessController.checkPermission ( AccessController.java:884) bij java.lang.SecurityManager.checkPermission (SecurityManager.java:549) bij com.baeldung.security.manager.Service.operation (Service.java:10)

We kunnen onze /.java.policy bestand met de volgende inhoud en probeer de applicatie opnieuw uit te voeren:

verlenen codeBase "bestand:" {toestemming com.baeldung.security.manager.CustomPermission "mijn-operatie"; };

Het werkt nu prima.

6. Conclusie

In dit artikel hebben we gecontroleerd hoe het ingebouwde JDK-beveiligingssysteem is georganiseerd en hoe we het kunnen uitbreiden. Hoewel het doelgebruik relatief zeldzaam is, is het goed om hiervan op de hoogte te zijn.

Zoals gewoonlijk is de volledige broncode voor dit artikel beschikbaar op GitHub.

Ik heb zojuist het nieuwe aangekondigd Leer de lente natuurlijk, gericht op de basisprincipes van Spring 5 en Spring Boot 2: