Les sections suivantes décrivent les formats pris en charge pour les listes d'URL. Les administrateurs peuvent spécifier le type de liste (regex ou exact) lors de l'appel à l' API REST Netskope V2 pour télécharger des listes d'URL.
Formats d'URL pris en charge
Cette section fournit des exemples de syntaxe autorisée dans les listes d'URL, tels que les caractères ou les espaces pris en charge dans les URL. En outre, la validation doit se faire à l'aide d'adresses URL exactes ou de caractères génériques. Des messages d'erreur spécifiques s'affichent en cas d'échec de la validation.
- Les URL malformées (espaces, caractères non ASCII) ne sont pas autorisées. Les URL contenant des caractères non ASCII doivent être correctement codés en pourcentage ("%" suivi de deux chiffres hexadécimaux).
- Le codage en pourcentage n'est pas autorisé dans le nom d'hôte. Il convient d'utiliser le punycode à la place.
- TLD (*.gov) sont autorisés.
- Erreur si plus d'un "*" est présent. Si "*" est présent, il doit s'agir du premier caractère. Il doit être suivi d'un point. Cela permet de faire correspondre tous les sous-domaines d'un domaine spécifié. Ainsi, "*.google.com" est correct, mais "*google.com" est correct. ou "www.google.*" ne le sont pas.
- Nous encourageons les utilisateurs à NE PAS ajouter de schéma (http/https) aux URL, car ils sont ignorés.
- user:password@host n'est pas pris en charge
- Les lignes vides sont ignorées
- Les lignes commençant par des caractères de commentaire ([# ;]) sont ignorées.
- Nom d'hôte : construit uniquement à partir de lettres, de chiffres et de tirets, ne peut pas commencer ou se terminer par un tiret, le codage en pourcentage n'est pas autorisé, le code puny est accepté.
- chemin, requête et fragment : toute combinaison de non réservée ([a-z0-9-._~]), encodage percent ( %[0-9a-f]{2} et délimiteurs ([ !$&' ()*+, ;=]) autorisé
- *.foo.com inclut automatiquement foo.com. Cela vous permet d'avoir une seule entrée (*.foo.com) au lieu de deux entrées (*.foo.com et foo.com) dans une liste d'URL pour dériver une catégorie personnalisée. Cette catégorie personnalisée peut être utilisée à différents endroits, par exemple dans une politique. Si vous créez d'autres configurations dans lesquelles les noms de domaine sont acceptés directement (comme une politique), vous devrez spécifier deux entrées distinctes pour correspondre aux sous-domaines ainsi qu'au domaine lui-même. Changements dans d'autres sous-systèmes Netskope pour fusionner *.domain.com et domain.com ne sont pas prises en charge actuellement.
Valid URL Examples
"# wildcard", "*.google.com", "# punycode", "xn--jp-cd2fp15c.xn--fsq.jp", "# percent encoded space", "www.apple.com/i%20mac", "https://onedrive.live.com/?authkey=%21AKD9vi-K9pXhFlw&cid=F3CDA5103641D53D&id=F3CDA5103641D53D%21157&parId=F3CDA5103641D53D%21110&o=OneUp",
Invalid URL Examples
# url with space "www.domain with space.com/some/path", "www.acme.com/path with space", "www.acme.com/some/path/foo.bar?q=query with space", # percent-encoding not allowed in domain; must use punycode "www.domain%20with%20space.com/some/path", # Invalid ip addresses "http://0.0.0.0", "http://1.2.3/some/path", "http://1.1.1.1.1/foo/bar", "http://123456789", # invalid port "WWW1.PYTHON2.ORG:65536/doc/#frag", "www.example.net:foo", "www.example.net:0", # invalid wildard "www.google.*", "*google.com", # empty host "?param=1", # username/password in host "https://user:password@www.acme.com:8080/path/to/search?P1=foo&P2=bar#Results"
Plages d'adresses IP et validation CIDR
Vous trouverez ci-dessous des considérations à prendre en compte pour les plages IP/CIDR, ainsi que des exemples.
- La plage d'adresses IP est spécifiée comme ABCD-WXYZ. L'adresse IP avec CIDR est spécifiée sous la forme ABCD/<bits>
- Une erreur est signalée si la plage d'adresses IP est suivie d'autres composants d'URL tels que le chemin d'accès et la requête. Si l'adresse IP/CIDR est suivie du chemin/de la requête, elle sera interprétée comme une URL exacte.
- L'adresse IP ne peut pas être 0.0.0.0. Dans une plage d'adresses IP, l'adresse de départ doit être inférieure à l'adresse d'arrivée. L'adresse IP en notation CIDR doit avoir une partie hôte égale à zéro.
- Les plages qui se chevauchent sont prises en charge. Si de telles plages sont associées à différentes catégories, la recherche d’adresses IP dans une plage qui se chevauche entraînerait plusieurs catégories. Par exemple, en considérant les deux plages suivantes, une recherche de 192.186.1.2 cela aboutirait à la dérivation de « Catégorie A » et « Catégorie B ».
- 192.186.1.1 – 192.168.1.4 (Catégorie A)
- 192.186.1.1 – 192.168.1.20 (Catégorie B)
Plages de validité et exemples de CIDR
# Range ok 192.168.1.10-192.168.1.20 # CIDR ok 192.168.1.0/24
Plages invalides et exemples de CIDR
# Invalid ip ranges and CIDR "http://1.2.3.20-1.2.3.10 "http://1.2.3.10-1.2.3.20/some/path" "http://1.2.3.4/24"
Le texte suivant est traité comme un URL exact au lieu d'une adresse IP et d'un CIDR, car le chemin d'accès à l'URL peut commencer par un chiffre.
"http://1.2.3.4/24/some/path"
Regex prises en charge
Vous trouverez ci-dessous des considérations à prendre en compte pour les listes de regex. En outre, cette section présente des exemples de regex et les formats pris en charge.
- Notre ensemble autorisé est PCRE (sans lookahead/lookbehind).
- Le schéma (http/https) dans l'expression rationnelle n'est pas pris en charge. Par exemple "https://.google.com" ne correspondra pas à l'URL entrant "travel.google.com"
- Le chemin d'accès à l'URL et les paramètres de la requête sont autorisés dans les expressions rationnelles et sont disponibles pour la correspondance.
- La rétro-référence et la capture de sous-expressions ne sont pas prises en charge.
- Caractères littéraux et chaînes de caractères
- Les classes de caractères telles que . (point), [abc] et [^abc], ainsi que les classes de caractères prédéfinies s, d, w, v et h et leurs contreparties négatives (S, D, W, V et H).
- Quantificateurs :
Les quantificateurs tels que ?, * et + sont pris en charge lorsqu'ils sont appliqués à des sous-expressions arbitraires prises en charge.
Les qualificateurs de répétition bornée tels que {n}, {m,n}, {n,} sont pris en charge avec des limitations. Pour des sous-motifs répétés arbitraires : n et m doivent être soit petits, soit infinis, par exemple (a|b){4}, (ab?c?d){4,10} ou (ab(cd)*){6,}.
- La parenthèse, y compris les formes nommées et non nommées, capturantes et non capturantes. Cependant, la capture est ignorée.
- Alternance avec le symbole |, comme dans foo|bar.
- Les ancres ^, $, A, Z et z.
- Modificateurs d’option – Ils permettent d’activer le comportement (avec ( ?<option>)) et de désactiver (avec ( ?-<option>)) pour un sous-pattern. Les options prises en charge sont :
- Correspondance insensible à la casse
- Correspondance multiligne
- Interpréter . comme "tout personnage"
- Syntaxe étendue, qui ignore la plupart des espaces dans le motif
Par exemple, l'expression foo(?i)bar(?-i)baz activera la correspondance insensible à la casse uniquement pour la partie bar de la correspondance.
Regex non prises en charge
Les constructions d'expressions rationnelles suivantes ne sont pas prises en charge :
- Rétro-références et capture de sous-expressions
- Verbes de contrôle du retour en arrière tels que (*SKIP) et (*PRUNE)
- Références de sous-programmes telles que (?1) où 1 est le numéro du groupe de capture.
- Motifs récursifs (?R), (?0), etc.
Valid Regex Examples
"^client[0-9]\.google\.com" # match client1.google.com, client2.google.com ...
"^app\.slack\.com\/.*\/netskope" # app.slack.com/foobar/netskope etc.
"^google\.com" # match google.com
"^www.foobar.com\/api\?action=create" # Match specific query parameter and value
"^sgr\d{1,3}.apple.com" # match sgr0.apple.com through sgr999.apple.com
Exemples de regex invalides
"((foo|bar)" # Missing close parenthesis for group started at index 0 "http://beginwith^[/]*/path" #Embedded start anchors not supported
Conseil
- Réduisez au minimum l'utilisation d'astérisques (*) dans vos expressions rationnelles, car ils peuvent entraîner un retour en arrière et avoir un impact sur les performances.
- La fonction de liste d'URL améliorée ne permet pas actuellement d'analyser et d'enregistrer les caractères réservés ou les codes ASCII hexagonaux. Backlash est un caractère réservé et doit être échappé pour que la liste d'URL puisse être sauvegardée avec succès. Cela s'applique uniquement à l'API, l'interface utilisateur n'est pas concernée.
Limites de la liste des URL
Actuellement, la limite totale des listes d'URL par locataire pour toutes les listes d'URL est de 300 000. La limite de liste d'URL utilisant Regex pour toutes les listes d'URL de ce locataire est de 1K (ce nombre de 1K ne comprend que les regex écrites et non le format étendu).
La limite par téléchargement est de 7 Mo (taille du fichier) et la limite susmentionnée du nombre d'URL et de Regex s'applique aux téléchargements effectués par l'intermédiaire de l'interface Web et de l'API REST V2. Vous pouvez télécharger plusieurs fichiers d'une taille de 7 Mo tant que la limite du nombre d'URL par locataire n'est pas dépassée.
Erreurs de validation
En cas d'échec de la validation, un message d'erreur spécifique est renvoyé. Par exemple :
"errors": [ [ "www.domain with space.com/some/path", "Invalid host" ], [ "www.acme.com/path with space", "Invalid Path" ],