Des milliers de magasins NetSuite fuient des données sensibles en raison d’une mauvaise configuration du contrôle d’accès

Comment cela conduit-il à des erreurs de configuration ?

Supposons qu’un administrateur crée un CRT avec « Aucune autorisation requise ». En ajoutant des champs personnalisés, il souhaite que certains champs soient lisibles par des utilisateurs non authentifiés. Il définit donc leur niveau d’accès par défaut sur Affichage ; d’autres champs qui ne doivent pas être lisibles, il définit le niveau d’accès par défaut sur Aucun, en supposant que le travail est terminé.

Cela serait incorrect car le paramètre « Niveau par défaut pour la recherche/rapport » (DLSR) est toujours Modifier, même si le niveau d’accès par défaut est défini sur Aucun. Et cela, montre Costello, peut être abusé via l’API NetSuite pour lire les données dans ce champ. La confusion ici pourrait être causée par le fait que les champs avec le niveau d’accès par défaut défini sur Aucun ne peuvent pas lire leurs données via la fonction loadRecord de l’API SuiteScript, qui fait partie du module N/record et contient les fonctions les plus populaires pour exécuter CRUD (créer , lire, mettre à jour, supprimer) opérations sur des enregistrements individuels.

Mais il existe une fonction API différente appelée nlapiSearchRecord, qui fait partie du module N/search, qui peut également être utilisée pour lire les données des champs d’enregistrement, et l’autorisation pour cette API est définie par le paramètre DLSR. La différence est que la lecture des valeurs de champ avec nlapiSearchRecord nécessite de connaître le nom du champ, tandis que la lecture des données via loadRecord nécessite de connaître l’ID du champ. Heureusement, les données pouvant être obtenues à partir des deux API se complètent.