Päritoluülene ressursside jagamine (CORS): konfiguratsioon ja turvalisuse parimad praktikad

Veebiarenduse maailmas on turvalisus esmatähtis. Üks kriitiline veebiturvalisuse aspekt on hallata, kuidas ühe päritoluga veebilehed saavad ligi ressurssidele teisest päritolust. Siin tuleb mängu päritoluülene ressursside jagamine (CORS). CORS on brauseri turvafunktsioon, mis piirab veebilehtedel päringute tegemist teisele domeenile kui see, mis veebilehe serveeris. See mehhanism on loodud selleks, et takistada pahatahtlikel veebisaitidel juurdepääsu tundlikele andmetele. See artikkel pakub põhjalikku juhendit CORS-i kohta, käsitledes selle konfiguratsiooni, turvamõjusid ja parimaid praktikaid.

Sama päritolu poliitika mõistmine

CORS on üles ehitatud sama päritolu poliitika vundamendile, mis on veebibrauserite poolt rakendatav fundamentaalne turvamehhanism. Sama päritolu poliitika piirab veebilehtedel päringute tegemist teisele domeenile kui see, mis veebilehe serveeris. Kahel URL-il loetakse olevat sama päritolu, kui neil on sama protokoll (nt HTTP või HTTPS), host (nt example.com) ja port (nt 80 või 443). Näiteks:

• http://example.com ja http://example.com/path on sama päritoluga.
• http://example.com ja https://example.com on erineva päritoluga (erinevad protokollid).
• http://example.com ja http://www.example.com on erineva päritoluga (erinevad hostid).
• http://example.com:80 ja http://example.com:8080 on erineva päritoluga (erinevad pordid).

Sama päritolu poliitika on loodud selleks, et vältida saidiülest skriptimist (Cross-Site Scripting, XSS), mille käigus pahatahtlik veebisait süstib usaldusväärsesse veebisaiti skripte kasutajaandmete varastamiseks või volitamata toimingute tegemiseks. Ilma sama päritolu poliitikata võiks pahatahtlik veebisait potentsiaalselt pääseda ligi teie pangakonto teabele, kui olete teises vahekaardis oma internetipanka sisse logitud.

Mis on päritoluülene ressursside jagamine (CORS)?

Kuigi sama päritolu poliitika on turvalisuse seisukohalt ülioluline, võib see olla piirav ka seaduslikes stsenaariumides, kus veebisaidid peavad pääsema juurde ressurssidele erinevatest päritoludest. Näiteks võib veebirakendus, mida hostitakse aadressil example.com, vajada andmete toomist API-st, mida hostitakse aadressil api.example.net. CORS pakub mehhanismi sama päritolu poliitikast kontrollitud viisil mööda hiilimiseks, võimaldades veebilehtedel teha päritoluüleseid päringuid, kui server on selleks selgesõnaliselt loa andnud.

CORS töötab, lisades serveri vastusele HTTP päised, mis näitavad, millistel päritoludel on ressursile juurdepääs lubatud. Brauser kontrollib seejärel neid päiseid ja blokeerib päringu, kui päringu tegeva veebilehe päritolu ei ole lubatud.

Kuidas CORS töötab: HTTP päised

CORS tugineb päritoluüleste päringute hõlbustamiseks spetsiifilistele HTTP päistele. Siin on peamised kaasatud päised:

1. Origin (päringu päis)

Origin päise saadab brauser päritoluülestes päringutes. See näitab päringu tegeva veebilehe päritolu (protokoll, host ja port). Näiteks:

            Origin: http://example.com
            

              
                Copy
              
            
          

2. Access-Control-Allow-Origin (vastuse päis)

Access-Control-Allow-Origin päis on CORS-i kõige olulisem päis. See määrab, millistel päritoludel on ressursile juurdepääs lubatud. Sellel võib olla üks järgmistest väärtustest:

• Konkreetne päritolu: Näiteks Access-Control-Allow-Origin: http://example.com lubab päringuid ainult aadressilt http://example.com.
• * (jokker): Access-Control-Allow-Origin: * lubab päringuid mis tahes päritolust. Seda tuleks kasutada ettevaatlikult, kuna see keelab selle ressursi jaoks sama päritolu poliitika.

Näide:

            Access-Control-Allow-Origin: https://www.example.com
            

              
                Copy
              
            
          

3. Access-Control-Allow-Methods (vastuse päis)

Access-Control-Allow-Methods päis määrab HTTP meetodid (nt GET, POST, PUT, DELETE), mis on päritoluüleses päringus lubatud. See on vajalik eelkontrolli päringute jaoks (selgitatud allpool).

Näide:

            Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
            

              
                Copy
              
            
          

4. Access-Control-Allow-Headers (vastuse päis)

Access-Control-Allow-Headers päis määrab HTTP päised, mis on päritoluüleses päringus lubatud. See on samuti vajalik eelkontrolli päringute jaoks.

Näide:

            Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With
            

              
                Copy
              
            
          

5. Access-Control-Allow-Credentials (vastuse päis)

Access-Control-Allow-Credentials päis määrab, kas brauser peaks päritoluülesesse päringusse kaasama autentimisandmeid (nt küpsised, autoriseerimispäised). Sellel võib olla üks kahest väärtusest: true või false. Kui on seatud true, ei saa Access-Control-Allow-Origin päist seada väärtusele *. See peab olema konkreetne päritolu.

Näide:

            Access-Control-Allow-Credentials: true
            

              
                Copy
              
            
          

6. Access-Control-Max-Age (vastuse päis)

Access-Control-Max-Age päis määrab sekundite arvu, mille jooksul brauser saab eelkontrolli päringu tulemusi vahemällu salvestada. See võib parandada jõudlust, vähendades eelkontrolli päringute arvu.

Näide:

            Access-Control-Max-Age: 3600
            

              
                Copy
              
            
          

Lihtsad päringud vs. eelkontrolli päringud

CORS eristab kahte tüüpi päritoluüleseid päringuid: lihtsad päringud ja eelkontrolli päringud.

Lihtsad päringud

Lihtne päring on päring, mis vastab järgmistele kriteeriumidele:

• Meetod on GET, HEAD või POST.
• Kui meetod on POST, on Content-Type päis üks järgmistest: application/x-www-form-urlencoded, multipart/form-data või text/plain.
• Päring ei sea ühtegi kohandatud päist (peale nende, mille brauser automaatselt seab).

Lihtsate päringute puhul saadab brauser päringu otse serverile. Server vastab seejärel asjakohaste CORS-i päistega. Kui päritolu on lubatud, töötleb brauser vastust. Vastasel juhul blokeerib brauser vastuse ja annab vea.

Eelkontrolli päringud

Eelkontrolli päringu saadab brauser enne tegeliku päritoluülese päringu tegemist, kui päring ei vasta lihtsa päringu kriteeriumidele. See juhtub tavaliselt siis, kui päring kasutab muud meetodit kui GET, HEAD või POST, või kui päring seab kohandatud päiseid.

Eelkontrolli päring on OPTIONS päring, mis sisaldab järgmisi päiseid:

• Origin: Päringu tegeva veebilehe päritolu.
• Access-Control-Request-Method: HTTP meetod, mida kasutatakse tegelikus päringus.
• Access-Control-Request-Headers: Komadega eraldatud loend kohandatud päistest, mida kasutatakse tegelikus päringus.

Server vastab seejärel järgmiste päistega:

• Access-Control-Allow-Origin: Päritolu, millel on ressursile juurdepääs lubatud.
• Access-Control-Allow-Methods: HTTP meetodid, mis on päritoluüleses päringus lubatud.
• Access-Control-Allow-Headers: HTTP päised, mis on päritoluüleses päringus lubatud.
• Access-Control-Max-Age: Sekundite arv, mille jooksul brauser saab eelkontrolli päringu tulemusi vahemällu salvestada.

Kui server vastab asjakohaste CORS-i päistega, jätkab brauser tegeliku päritoluülese päringuga. Vastasel juhul blokeerib brauser päringu ja annab vea.

CORS-i konfiguratsiooninäited

CORS-i rakendamine sõltub kasutatavast serveripoolsest tehnoloogiast. Siin on mõned näited levinumate serveripoolsete keelte ja raamistike jaoks:

Node.js koos Expressiga

cors vahevara kasutamine on levinud lähenemine CORS-i konfigureerimiseks Node.js-is koos Expressiga:

            const express = require('express');
const cors = require('cors');
const app = express();

// Luba CORS kõikidele päritoludele
app.use(cors());

// Luba CORS konkreetsele päritolule
// app.use(cors({ origin: 'http://example.com' }));

// Luba CORS valikutega
// app.use(cors({
//   origin: ['http://example.com', 'http://localhost:3000'],
//   methods: ['GET', 'POST', 'PUT', 'DELETE'],
//   allowedHeaders: ['Content-Type', 'Authorization'],
//   credentials: true
// }));

app.get('/api/data', (req, res) => {
  res.json({ message: 'Hello from the API!' });
});

app.listen(3001, () => {
  console.log('Server listening on port 3001');
});

            

              
                Copy
              
            
          

Python koos Flaskiga

CORS-i konfigureerimiseks Flaskis saate kasutada Flask-CORS laiendust:

            from flask import Flask
from flask_cors import CORS

app = Flask(__name__)

# Luba CORS kõikidele päritoludele
CORS(app)

# Luba CORS konkreetsetele päritoludele
# CORS(app, origins=['http://example.com', 'http://localhost:3000'])

@app.route('/api/data')
def get_data():
    return {'message': 'Hello from the API!'}

if __name__ == '__main__':
    app.run(port=3001)

            

              
                Copy
              
            
          

Java koos Spring Bootiga

Spring Boot pakub mitmeid viise CORS-i konfigureerimiseks. Üks lähenemine on kasutada @CrossOrigin annotatsiooni:

            import org.springframework.web.bind.annotation.CrossOrigin;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@CrossOrigin(origins = "http://example.com") // Konkreetne päritolu
public class ApiController {

    @GetMapping("/api/data")
    public String getData() {
        return "Hello from the API!";
    }
}

// Globaalne CORS-i konfiguratsioon (kasutades WebMvcConfigurer):

// @Configuration
// public class CorsConfig implements WebMvcConfigurer {

//     @Override
//     public void addCorsMappings(CorsRegistry registry) {
//         registry.addMapping("/**")
//                 .allowedOrigins("http://example.com", "http://localhost:3000")
//                 .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
//                 .allowedHeaders("Content-Type", "Authorization")
//                 .allowCredentials(true)
//                 .maxAge(3600);
//     }
// }

            

              
                Copy
              
            
          

PHP

PHP-s saate CORS-i päised otse oma skriptis seada:

            <?php
header("Access-Control-Allow-Origin: http://example.com");
header("Content-Type: application/json");

$data = array("message" => "Hello from the API!");
echo json_encode($data);
?>

            

              
                Copy
              
            
          

CORS-i turvakaalutlused

Kuigi CORS võimaldab päritoluüleseid päringuid, on haavatavuste vältimiseks ülioluline mõista turvamõjusid ja rakendada seda õigesti.

1. Vältige Access-Control-Allow-Origin: * kasutamist tootmises

Jokkeri * kasutamine Access-Control-Allow-Origin päises lubab päringuid mis tahes päritolust, keelates selle ressursi jaoks sama päritolu poliitika. See võib teie API paljastada pahatahtlikele veebisaitidele, mis võivad potentsiaalselt varastada kasutajaandmeid või sooritada volitamata toiminguid. Selle asemel määrake täpsed päritolud, millel on ressursile juurdepääs lubatud. Näiteks kui teie veebirakendus on hostitud aadressil example.com ja peab pääsema juurde API-le, mis on hostitud aadressil api.example.com, seadke päiseks Access-Control-Allow-Origin: http://example.com.

Globaalne näide: kujutage ette finantsteenuste API-d, mis seab Access-Control-Allow-Origin: *. Pahatahtlik veebisait võiks seejärel teha päringuid sellele API-le sisselogitud kasutaja nimel, potentsiaalselt kandes raha üle ilma kasutaja teadmata.

2. Valideerige Origin päis serveris

Isegi kui määrate lubatud päritolude loendi, on oluline valideerida Origin päis serveris, et vältida ründajatel päritolu võltsimist. Ründaja võib potentsiaalselt saata päringu võltsitud Origin päisega, et CORS-i kontrollidest mööda hiilida. Selle leevendamiseks võrrelge Origin päist usaldusväärsete päritolude loendiga serveripoolel. Kui päritolu ei ole loendis, lükake päring tagasi.

Globaalne näide: kaaluge e-kaubanduse platvormi. Ründaja võib püüda jäljendada seadusliku poe Origin päritolu, et pääseda ligi tundlikele kliendiandmetele e-kaubanduse platvormi API-st.

3. Olge ettevaatlik Access-Control-Allow-Credentials: true kasutamisega

Kui seate Access-Control-Allow-Credentials: true, ei saa Access-Control-Allow-Origin päist seada väärtusele *. See peab olema konkreetne päritolu. See on tingitud asjaolust, et autentimisandmete lubamine mis tahes päritolust võib luua turvariski, kuna see võib lubada pahatahtlikel veebisaitidel juurdepääsu kasutajaandmetele, kui nad suudavad kasutajat meelitada külastama oma saiti, samal ajal kui kasutaja on sisse logitud ka sihtveebisaidile. See seadistus on oluline küpsiste või autoriseerimispäiste käsitlemisel.

Globaalne näide: sotsiaalmeedia platvorm, mis lubab päritoluüleseid päringuid autentimisandmetega, nõuab hoolikat haldamist, et vältida volitamata juurdepääsu kasutajakontodele.

4. Konfigureerige Access-Control-Allow-Methods ja Access-Control-Allow-Headers õigesti

Lubage ainult need HTTP meetodid ja päised, mis on päritoluüleste päringute jaoks vajalikud. Kui peate lubama ainult GET ja POST päringuid, ärge lubage PUT, DELETE ega muid meetodeid. Samamoodi lubage ainult need konkreetsed päised, mida teie rakendus vajab. Liiga lubavad konfiguratsioonid võivad suurendada rünnakute riski.

Globaalne näide: CRM-süsteem peaks paljastama ainult vajalikud API lõpp-punktid ja päised volitatud kolmandate osapoolte integratsioonidele, minimeerides rünnakupinda.

5. Kasutage HTTPS-i turvaliseks suhtluseks

Kasutage alati HTTPS-i turvaliseks suhtluseks brauseri ja serveri vahel. HTTPS krüpteerib brauseri ja serveri vahel edastatavad andmed, vältides pealtkuulamist ja man-in-the-middle rünnakuid. HTTP kasutamine võib paljastada tundlikke andmeid ründajatele, isegi kui CORS on õigesti konfigureeritud.

Globaalne näide: tervishoiurakendused peavad kasutama HTTPS-i, et kaitsta erinevate päritolude vahel edastatavaid patsiendiandmeid.

6. Sisuturbe poliitika (CSP)

Kuigi see ei ole otseselt seotud CORS-iga, on sisuturbe poliitika (Content Security Policy, CSP) veel üks oluline turvamehhanism, mis aitab vältida XSS-rünnakuid. CSP võimaldab teil määratleda lubatud nimekirja allikatest, kust brauseril on lubatud ressursse laadida. See aitab vältida ründajatel pahatahtlike skriptide süstimist teie veebisaidile, isegi kui neil õnnestub teistest turvameetmetest mööda hiilida.

Globaalne näide: finantsasutused kasutavad sageli rangeid CSP poliitikaid, et piirata oma internetipanga portaalidesse laaditava sisu allikaid, vähendades XSS-rünnakute riski.

Levinud CORS-i probleemid ja tõrkeotsing

CORS-i vigade silumine võib olla masendav. Siin on mõned levinud probleemid ja kuidas neid lahendada:

1. "No 'Access-Control-Allow-Origin' header is present on the requested resource."

See on kõige levinum CORS-i viga. See näitab, et server ei tagasta oma vastuses Access-Control-Allow-Origin päist. Veenduge, et server on konfigureeritud saatma õigeid CORS-i päiseid päringut tegeva veebilehe päritolu jaoks. Kontrollige oma serveripoolset koodi ja konfiguratsioonifaile topelt.

2. "Response to preflight request doesn't pass access control check: It does not have HTTP ok status."

See viga näitab, et eelkontrolli päring ebaõnnestus. See võib juhtuda, kui server ei vasta OPTIONS päringutele või kui server tagastab eelkontrolli päringu vastuseks veakoodi (nt 404, 500). Veenduge, et teie server on konfigureeritud käsitlema OPTIONS päringuid ja et see tagastab 200 OK staatuskoodi.

3. "Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'."

See viga ilmneb, kui proovite saata autentimisandmeid (nt küpsiseid) päritoluüleses päringus ja Access-Control-Allow-Origin päis on seatud väärtusele *. Nagu varem mainitud, ei saa te autentimisandmete saatmisel kasutada jokkerit *. Peate määrama täpse päritolu, millel on ressursile juurdepääs lubatud.

4. Brauseri vahemälu

Brauserid võivad CORS-i vastuseid vahemällu salvestada, mis võib põhjustada ootamatut käitumist, kui CORS-i konfiguratsioon muutub. Vahemäluprobleemide vältimiseks seadke vastuse Cache-Control päis väärtusele no-cache, no-store või max-age=0. Saate kasutada ka Access-Control-Max-Age päist, et kontrollida, kui kaua brauser eelkontrolli päringu tulemusi vahemällu salvestab.

Alternatiivid CORS-ile

Kuigi CORS on standardne viis päritoluüleste päringute lubamiseks, on teatud stsenaariumides mõningaid alternatiive, mida võite kaaluda:

1. JSON with Padding (JSONP)

JSONP on tehnika, mis kasutab <script> silti sama päritolu poliitikast mööda hiilimiseks. JSONP töötab, mähkides JSON-andmed JavaScripti funktsioonikutsesse. Brauser täidab seejärel JavaScripti funktsiooni, edastades JSON-andmed argumendina. JSONP-d on lihtsam rakendada kui CORS-i, kuid sellel on mõned piirangud. See toetab ainult GET päringuid ja on vähem turvaline kui CORS.

2. Pöördpuhverserver

Pöördpuhverserver on server, mis asub teie API serveri ees ja edastab sellele päringuid. Pöördpuhverserveri saab konfigureerida lisama vastusele vajalikud CORS-i päised, varjates sellega päritoluülesed päringud brauseri eest. See lähenemine võib olla kasulik, kui teil pole API serveri üle kontrolli või kui soovite CORS-i konfiguratsiooni lihtsustada.

Kokkuvõte

Päritoluülene ressursside jagamine (CORS) on ülioluline turvamehhanism, mis võimaldab veebilehtedel kontrollitud viisil juurde pääseda ressurssidele erinevatest päritoludest. CORS-i toimimise mõistmine ja selle õige rakendamine on turvaliste ja usaldusväärsete veebirakenduste loomisel hädavajalik. Järgides selles artiklis toodud parimaid praktikaid, saate CORS-i tõhusalt hallata ja kaitsta oma API-sid volitamata juurdepääsu eest.

Pidage meeles, et CORS-i konfigureerimisel tuleb alati eelistada turvalisust. Vältige jokkerite kasutamist, valideerige Origin päis ja kasutage turvaliseks suhtluseks HTTPS-i. Neid ettevaatusabinõusid rakendades saate tagada, et teie veebirakendused on kaitstud saidiüleste rünnakute eest.

See põhjalik juhend annab kindla aluse CORS-i mõistmiseks. Kõige ajakohasema teabe ja parimate praktikate saamiseks vaadake alati oma konkreetse serveripoolse tehnoloogia ametlikku dokumentatsiooni. Hoidke end kursis tekkivate turvaohtudega ja kohandage oma CORS-i konfiguratsiooni vastavalt.