Eltérő eredetű erőforrás-megosztás (CORS): Konfiguráció és biztonsági legjobb gyakorlatok

A webfejlesztés világában a biztonság elsődleges. A webbiztonság egyik kritikus aspektusa annak kezelése, hogy egy adott eredetű weboldal hogyan férhet hozzá egy másik eredetű erőforrásokhoz. Itt jön képbe az Eltérő Eredetű Erőforrás-Megosztás (CORS). A CORS egy böngészőbiztonsági funkció, amely korlátozza a weboldalakat abban, hogy a weboldalt kiszolgáló doméntől eltérő doménhez intézzenek kéréseket. Ez a mechanizmus azért van érvényben, hogy megakadályozza a rosszindulatú webhelyek hozzáférését az érzékeny adatokhoz. Ez a cikk átfogó útmutatót nyújt a CORS-hoz, kitérve annak konfigurációjára, biztonsági következményeire és legjobb gyakorlataira.

Az Azonos Eredetű Irányelv (Same-Origin Policy) megértése

A CORS az Azonos Eredetű Irányelv (Same-Origin Policy) alapjaira épül, amely egy alapvető biztonsági mechanizmus, amit a webböngészők valósítanak meg. Az azonos eredetű irányelv korlátozza a weboldalakat abban, hogy a weboldalt kiszolgáló doméntől eltérő doménhez intézzenek kéréseket. Két URL akkor tekinthető azonos eredetűnek, ha azonos a protokolljuk (pl. HTTP vagy HTTPS), a hosztjuk (pl. example.com) és a portjuk (pl. 80 vagy 443). Például:

• http://example.com és http://example.com/path azonos eredetűek.
• http://example.com és https://example.com különböző eredetűek (eltérő protokollok).
• http://example.com és http://www.example.com különböző eredetűek (eltérő hosztok).
• http://example.com:80 és http://example.com:8080 különböző eredetűek (eltérő portok).

Az azonos eredetű irányelv célja a Cross-Site Scripting (XSS) támadások megakadályozása, ahol egy rosszindulatú webhely szkripteket injektál egy megbízható webhelybe felhasználói adatok ellopása vagy jogosulatlan műveletek végrehajtása érdekében. Az azonos eredetű irányelv nélkül egy rosszindulatú webhely potenciálisan hozzáférhetne a bankszámla-információihoz, ha Ön egy másik fülön be lenne jelentkezve az online banki portáljára.

Mi az az Eltérő Eredetű Erőforrás-Megosztás (CORS)?

Bár az azonos eredetű irányelv kulcsfontosságú a biztonság szempontjából, korlátozó is lehet olyan jogos esetekben, amikor a webhelyeknek különböző eredetű erőforrásokhoz kell hozzáférniük. Például egy, az example.com címen hosztolt webalkalmazásnak adatokat kell lekérnie egy, az api.example.net címen hosztolt API-tól. A CORS egy mechanizmust biztosít az azonos eredetű irányelv ellenőrzött módon történő megkerülésére, lehetővé téve a weboldalak számára, hogy eltérő eredetű kéréseket tegyenek, ha a szerver ezt kifejezetten engedélyezi.

A CORS úgy működik, hogy HTTP fejléceket ad hozzá a szerver válaszához, jelezve, hogy mely eredetek férhetnek hozzá az erőforráshoz. A böngésző ezután ellenőrzi ezeket a fejléceket, és letiltja a kérést, ha a kérést küldő weboldal eredete nem engedélyezett.

Hogyan működik a CORS: A HTTP fejlécek

A CORS meghatározott HTTP fejlécekre támaszkodik az eltérő eredetű kérések megkönnyítése érdekében. Íme a legfontosabb érintett fejlécek:

1. Origin (Kérés fejléc)

Az Origin fejlécet a böngésző küldi az eltérő eredetű kérésekben. Ez jelzi a kérést indító weboldal eredetét (protokoll, hoszt és port). Például:

            Origin: http://example.com
            

              
                Copy
              
            
          

2. Access-Control-Allow-Origin (Válasz fejléc)

Az Access-Control-Allow-Origin fejléc a legfontosabb a CORS-ban. Meghatározza, hogy mely eredetek férhetnek hozzá az erőforráshoz. A következő értékek egyike lehet:

• Egy konkrét eredet: Például az Access-Control-Allow-Origin: http://example.com csak az http://example.com címről érkező kéréseket engedélyezi.
• * (helyettesítő karakter): Az Access-Control-Allow-Origin: * bármely eredetből érkező kérést engedélyez. Ezt óvatosan kell használni, mivel gyakorlatilag letiltja az azonos eredetű irányelvet az adott erőforrásra.

Példa:

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

              
                Copy
              
            
          

3. Access-Control-Allow-Methods (Válasz fejléc)

Az Access-Control-Allow-Methods fejléc meghatározza az eltérő eredetű kérésben engedélyezett HTTP metódusokat (pl. GET, POST, PUT, DELETE). Erre az előzetes kéréseknél (preflight requests) van szükség (lásd alább).

Példa:

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

              
                Copy
              
            
          

4. Access-Control-Allow-Headers (Válasz fejléc)

Az Access-Control-Allow-Headers fejléc meghatározza az eltérő eredetű kérésben engedélyezett HTTP fejléceket. Erre szintén az előzetes kéréseknél van szükség.

Példa:

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

              
                Copy
              
            
          

5. Access-Control-Allow-Credentials (Válasz fejléc)

Az Access-Control-Allow-Credentials fejléc meghatározza, hogy a böngészőnek tartalmaznia kell-e a hitelesítő adatokat (pl. sütik, engedélyezési fejlécek) az eltérő eredetű kérésben. Két értéke lehet: true vagy false. Ha true értékre van állítva, az Access-Control-Allow-Origin fejléc nem lehet *. Annak egy konkrét eredetnek kell lennie.

Példa:

            Access-Control-Allow-Credentials: true
            

              
                Copy
              
            
          

6. Access-Control-Max-Age (Válasz fejléc)

Az Access-Control-Max-Age fejléc másodpercekben adja meg, hogy a böngésző mennyi ideig gyorsítótárazhatja az előzetes kérés eredményeit. Ez javíthatja a teljesítményt az előzetes kérések számának csökkentésével.

Példa:

            Access-Control-Max-Age: 3600
            

              
                Copy
              
            
          

Egyszerű kérések vs. előzetes kérések (Preflight Requests)

A CORS kétféle eltérő eredetű kérést különböztet meg: egyszerű kéréseket és előzetes kéréseket.

Egyszerű kérések

Egy egyszerű kérés olyan kérés, amely megfelel a következő feltételeknek:

• A metódus GET, HEAD vagy POST.
• Ha a metódus POST, a Content-Type fejléc a következők egyike: application/x-www-form-urlencoded, multipart/form-data vagy text/plain.
• A kérés nem állít be egyéni fejléceket (kivéve azokat, amelyeket a böngésző automatikusan beállít).

Egyszerű kérések esetén a böngésző közvetlenül elküldi a kérést a szervernek. A szerver ezután a megfelelő CORS fejlécekkel válaszol. Ha az eredet engedélyezett, a böngésző feldolgozza a választ. Ellenkező esetben a böngésző letiltja a választ és hibát dob.

Előzetes kérések

Az előzetes kérést (preflight request) a böngésző küldi el a tényleges eltérő eredetű kérés előtt, ha a kérés nem felel meg az egyszerű kérés feltételeinek. Ez általában akkor fordul elő, ha a kérés nem GET, HEAD vagy POST metódust használ, vagy ha a kérés egyéni fejléceket állít be.

Az előzetes kérés egy OPTIONS kérés, amely a következő fejléceket tartalmazza:

• Origin: A kérést indító weboldal eredete.
• Access-Control-Request-Method: A tényleges kérésben használandó HTTP metódus.
• Access-Control-Request-Headers: A tényleges kérésben használandó egyéni fejlécek vesszővel elválasztott listája.

A szerver ezután a következő fejlécekkel válaszol:

• Access-Control-Allow-Origin: Az erőforráshoz hozzáférni engedélyezett eredet.
• Access-Control-Allow-Methods: Az eltérő eredetű kérésben engedélyezett HTTP metódusok.
• Access-Control-Allow-Headers: Az eltérő eredetű kérésben engedélyezett HTTP fejlécek.
• Access-Control-Max-Age: Az időtartam másodpercekben, ameddig a böngésző gyorsítótárazhatja az előzetes kérés eredményeit.

Ha a szerver a megfelelő CORS fejlécekkel válaszol, a böngésző folytatja a tényleges eltérő eredetű kéréssel. Ellenkező esetben a böngésző letiltja a kérést és hibát dob.

CORS konfigurációs példák

A CORS implementációja a használt szerveroldali technológiától függ. Íme néhány példa gyakori szerveroldali nyelvekre és keretrendszerekre:

Node.js Express-szel

A cors middleware használata gyakori megközelítés a CORS konfigurálására Node.js-ben Express-szel:

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

// CORS engedélyezése minden eredet számára
app.use(cors());

// CORS engedélyezése egy adott eredet számára
// app.use(cors({ origin: 'http://example.com' }));

// CORS engedélyezése opciókkal
// 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 Flask-kal

A Flask-CORS kiterjesztést használhatja a CORS konfigurálására Flask-ban:

            from flask import Flask
from flask_cors import CORS

app = Flask(__name__)

# CORS engedélyezése minden eredet számára
CORS(app)

# CORS engedélyezése adott eredetek számára
# 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 Spring Boot-tal

A Spring Boot többféle módon teszi lehetővé a CORS konfigurálását. Az egyik megközelítés a @CrossOrigin annotáció használata:

            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") // Adott eredet
public class ApiController {

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

// Globális CORS konfiguráció (WebMvcConfigurer használatával):

// @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-ban közvetlenül a szkriptben állíthatja be a CORS fejléceket:

            <?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 biztonsági megfontolások

Bár a CORS lehetővé teszi az eltérő eredetű kéréseket, kulcsfontosságú megérteni a biztonsági következményeket és helyesen implementálni, hogy elkerüljük a sebezhetőségeket.

1. Kerülje az Access-Control-Allow-Origin: * használatát éles környezetben

A * helyettesítő karakter használata az Access-Control-Allow-Origin fejlécben bármely eredetből érkező kéréseket engedélyez, ami gyakorlatilag letiltja az azonos eredetű irányelvet az adott erőforrásra. Ez kiteheti az API-ját rosszindulatú webhelyeknek, amelyek potenciálisan ellophatják a felhasználói adatokat vagy jogosulatlan műveleteket hajthatnak végre. Ehelyett adja meg pontosan azokat az eredeteket, amelyek hozzáférhetnek az erőforráshoz. Például, ha a webalkalmazása az example.com címen van hosztolva és egy API-hoz kell hozzáférnie az api.example.com címen, állítsa a fejlécet Access-Control-Allow-Origin: http://example.com értékre.

Globális példa: Képzeljünk el egy pénzügyi szolgáltatást nyújtó API-t, amely Access-Control-Allow-Origin: * beállítást használ. Egy rosszindulatú webhely ezután kéréseket intézhetne ehhez az API-hoz egy bejelentkezett felhasználó nevében, potenciálisan pénzt utalva a felhasználó tudta nélkül.

2. Ellenőrizze az Origin fejlécet a szerveren

Még ha meg is ad egy listát az engedélyezett eredetekről, fontos ellenőrizni az Origin fejlécet a szerveren, hogy megakadályozzuk a támadókat az eredet hamisításában. Egy támadó potenciálisan hamisított Origin fejléccel küldhet kérést, hogy megkerülje a CORS ellenőrzéseket. Ennek enyhítésére hasonlítsa össze az Origin fejlécet egy megbízható eredetek listájával a szerveroldalon. Ha az eredet nincs a listában, utasítsa el a kérést.

Globális példa: Vegyünk egy e-kereskedelmi platformot. Egy támadó megpróbálhatja utánozni egy legitim áruház Origin-jét, hogy hozzáférjen érzékeny vásárlói adatokhoz az e-kereskedelmi platform API-jából.

3. Legyen óvatos az Access-Control-Allow-Credentials: true beállítással

Ha az Access-Control-Allow-Credentials: true értéket állítja be, az Access-Control-Allow-Origin fejléc nem lehet *. Annak egy konkrét eredetnek kell lennie. Ennek oka az, hogy a hitelesítő adatok bármely eredetből történő engedélyezése biztonsági kockázatot jelenthet, mivel lehetővé teheti rosszindulatú webhelyek számára a felhasználói adatokhoz való hozzáférést, ha rá tudnak venni egy felhasználót, hogy látogasson el az oldalukra, miközben a felhasználó be van jelentkezve a célwebhelyre is. Ez a beállítás fontos, amikor sütikkel vagy engedélyezési fejlécekkel dolgozunk.

Globális példa: Egy közösségi média platform, amely engedélyezi a hitelesítő adatokkal rendelkező, eltérő eredetű kéréseket, gondos kezelést igényel a felhasználói fiókokhoz való jogosulatlan hozzáférés megakadályozása érdekében.

4. Konfigurálja helyesen az Access-Control-Allow-Methods és Access-Control-Allow-Headers fejléceket

Csak azokat a HTTP metódusokat és fejléceket engedélyezze, amelyek szükségesek az eltérő eredetű kérésekhez. Ha csak GET és POST kéréseket kell engedélyeznie, ne engedélyezze a PUT, DELETE vagy más metódusokat. Hasonlóképpen, csak azokat a konkrét fejléceket engedélyezze, amelyekre az alkalmazásának szüksége van. A túlságosan megengedő konfigurációk növelhetik a támadások kockázatát.

Globális példa: Egy CRM rendszernek csak a szükséges API végpontokat és fejléceket kellene kitennie az engedélyezett harmadik feles integrációk számára, minimalizálva a támadási felületet.

5. Használjon HTTPS-t a biztonságos kommunikációhoz

Mindig használjon HTTPS-t a böngésző és a szerver közötti biztonságos kommunikációhoz. A HTTPS titkosítja a böngésző és a szerver között továbbított adatokat, megakadályozva a lehallgatást és a man-in-the-middle támadásokat. A HTTP használata kiteheti az érzékeny adatokat a támadóknak, még akkor is, ha a CORS helyesen van konfigurálva.

Globális példa: Az egészségügyi alkalmazásoknak HTTPS-t kell használniuk a különböző eredetek között továbbított betegadatok védelme érdekében.

6. Tartalombiztonsági Irányelv (Content Security Policy - CSP)

Bár nem közvetlenül kapcsolódik a CORS-hoz, a Tartalombiztonsági Irányelv (CSP) egy másik fontos biztonsági mechanizmus, amely segíthet megelőzni az XSS támadásokat. A CSP lehetővé teszi, hogy meghatározzon egy fehérlistát azokról a forrásokról, ahonnan a böngésző erőforrásokat tölthet be. Ez segíthet megakadályozni, hogy a támadók rosszindulatú szkripteket injektáljanak a webhelyére, még akkor is, ha sikerül megkerülniük más biztonsági intézkedéseket.

Globális példa: A pénzintézetek gyakran szigorú CSP irányelveket alkalmaznak, hogy korlátozzák az online banki portáljaikra betöltött tartalom forrásait, csökkentve az XSS támadások kockázatát.

Gyakori CORS problémák és hibaelhárítás

A CORS hibák hibakeresése frusztráló lehet. Íme néhány gyakori probléma és azok elhárítása:

1. "No 'Access-Control-Allow-Origin' header is present on the requested resource." (Nincs 'Access-Control-Allow-Origin' fejléc a kért erőforráson.)

Ez a leggyakoribb CORS hiba. Azt jelzi, hogy a szerver nem küldi vissza az Access-Control-Allow-Origin fejlécet a válaszában. Győződjön meg róla, hogy a szerver úgy van konfigurálva, hogy a kérést indító weboldal eredetéhez a megfelelő CORS fejléceket küldje. Ellenőrizze duplán a szerveroldali kódot és a konfigurációs fájlokat.

2. "Response to preflight request doesn't pass access control check: It does not have HTTP ok status." (Az előzetes kérésre adott válasz nem megy át a hozzáférés-ellenőrzésen: Nincs HTTP ok státusza.)

Ez a hiba azt jelzi, hogy az előzetes kérés sikertelen volt. Ez akkor fordulhat elő, ha a szerver nem válaszol az OPTIONS kérésekre, vagy ha a szerver hibakódot (pl. 404, 500) ad vissza az előzetes kérésre. Győződjön meg róla, hogy a szervere úgy van konfigurálva, hogy kezelje az OPTIONS kéréseket, és hogy 200 OK státuszkódot ad vissza.

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'." (Az előzetes kérésre adott válasz nem megy át a hozzáférés-ellenőrzésen: Az 'Access-Control-Allow-Origin' fejléc értéke a válaszban nem lehet a '*' helyettesítő karakter, ha a kérés hitelesítési módja 'include'.)

Ez a hiba akkor jelentkezik, amikor hitelesítő adatokat (pl. sütiket) próbál küldeni egy eltérő eredetű kérésben, és az Access-Control-Allow-Origin fejléc *-ra van állítva. Ahogy korábban említettük, nem használhatja a * helyettesítő karaktert hitelesítő adatok küldésekor. Meg kell adnia a pontos eredetet, amely hozzáférhet az erőforráshoz.

4. Böngésző gyorsítótárazás

A böngészők gyorsítótárazhatják a CORS válaszokat, ami váratlan viselkedéshez vezethet, ha a CORS konfiguráció megváltozik. A gyorsítótárazási problémák elkerülése érdekében állítsa a Cache-Control fejlécet a válaszban no-cache, no-store vagy max-age=0 értékre. Az Access-Control-Max-Age fejlécet is használhatja annak szabályozására, hogy a böngésző mennyi ideig gyorsítótárazza az előzetes kérés eredményeit.

A CORS alternatívái

Bár a CORS a szabványos módja az eltérő eredetű kérések engedélyezésének, léteznek alternatívák, amelyeket bizonyos esetekben megfontolhat:

1. JSON with Padding (JSONP)

A JSONP egy olyan technika, amely a <script> taget használja az azonos eredetű irányelv megkerülésére. A JSONP úgy működik, hogy a JSON adatokat egy JavaScript függvényhívásba csomagolja. A böngésző ezután végrehajtja a JavaScript függvényt, átadva a JSON adatokat argumentumként. A JSONP egyszerűbben implementálható, mint a CORS, de vannak korlátai. Csak a GET kéréseket támogatja, és kevésbé biztonságos, mint a CORS.

2. Fordított proxy (Reverse Proxy)

A fordított proxy egy olyan szerver, amely az API szerver előtt helyezkedik el és továbbítja hozzá a kéréseket. A fordított proxyt úgy lehet konfigurálni, hogy hozzáadja a szükséges CORS fejléceket a válaszhoz, hatékonyan elrejtve az eltérő eredetű kéréseket a böngésző elől. Ez a megközelítés hasznos lehet, ha nincs kontrollja az API szerver felett, vagy ha egyszerűsíteni szeretné a CORS konfigurációt.

Összegzés

Az Eltérő Eredetű Erőforrás-Megosztás (CORS) egy kulcsfontosságú biztonsági mechanizmus, amely lehetővé teszi a weboldalak számára, hogy ellenőrzött módon hozzáférjenek különböző eredetű erőforrásokhoz. A CORS működésének megértése és helyes implementálása elengedhetetlen a biztonságos és megbízható webalkalmazások építéséhez. Az ebben a cikkben felvázolt legjobb gyakorlatok követésével hatékonyan kezelheti a CORS-t és megvédheti API-jait a jogosulatlan hozzáféréstől.

Ne feledje, hogy a CORS konfigurálásakor mindig a biztonságot helyezze előtérbe. Kerülje a helyettesítő karakterek használatát, ellenőrizze az Origin fejlécet, és használjon HTTPS-t a biztonságos kommunikációhoz. Ezen óvintézkedések megtételével biztosíthatja, hogy webalkalmazásai védve legyenek a cross-site támadásokkal szemben.

Ez az átfogó útmutató szilárd alapot nyújt a CORS megértéséhez. Mindig olvassa el az adott szerveroldali technológia hivatalos dokumentációját a legfrissebb információkért és legjobb gyakorlatokért. Legyen tájékozott a felmerülő biztonsági fenyegetésekről, és ennek megfelelően igazítsa a CORS konfigurációját.