# Angular
{{#include ../../banners/hacktricks-training.md}}
## La Liste de Vérification
Checklist [from here](https://lsgeurope.com/post/angular-security-checklist).
* [ ] Angular est considéré comme un framework côté client et n'est pas censé fournir de protection côté serveur
* [ ] Le sourcemap pour les scripts est désactivé dans la configuration du projet
* [ ] Les entrées utilisateur non fiables sont toujours interpolées ou assainies avant d'être utilisées dans les templates
* [ ] L'utilisateur n'a aucun contrôle sur les templates côté serveur ou côté client
* [ ] Les entrées utilisateur non fiables sont assainies en utilisant un contexte de sécurité approprié avant d'être considérées comme fiables par l'application
* [ ] Les méthodes `BypassSecurity*` ne sont pas utilisées avec des entrées non fiables
* [ ] Les entrées utilisateur non fiables ne sont pas passées aux classes Angular telles que `ElementRef`, `Renderer2` et `Document`, ou à d'autres sinks JQuery/DOM
## Qu'est-ce qu'Angular
Angular est un **framework** front-end **puissant** et **open-source** maintenu par **Google**. Il utilise **TypeScript** pour améliorer la lisibilité du code et le débogage. Avec de forts mécanismes de sécurité, Angular prévient les vulnérabilités courantes côté client comme **XSS** et **redirections ouvertes**. Il peut également être utilisé côté **serveur**, rendant les considérations de sécurité importantes des **deux côtés**.
## Architecture du framework
Afin de mieux comprendre les bases d'Angular, passons en revue ses concepts essentiels.
Un projet Angular commun ressemble généralement à :
```bash
my-workspace/
├── ... #workspace-wide configuration files
├── src
│ ├── app
│ │ ├── app.module.ts #defines the root module, that tells Angular how to assemble the application
│ │ ├── app.component.ts #defines the logic for the application's root component
│ │ ├── app.component.html #defines the HTML template associated with the root component
│ │ ├── app.component.css #defines the base CSS stylesheet for the root component
│ │ ├── app.component.spec.ts #defines a unit test for the root component
│ │ └── app-routing.module.ts #provides routing capability for the application
│ ├── lib
│ │ └── src #library-specific configuration files
│ ├── index.html #main HTML page, where the component will be rendered in
│ └── ... #application-specific configuration files
├── angular.json #provides workspace-wide and project-specific configuration defaults
└── tsconfig.json #provides the base TypeScript configuration for projects in the workspace
```
Selon la documentation, chaque application Angular a au moins un composant, le composant racine (`AppComponent`) qui connecte une hiérarchie de composants avec le DOM. Chaque composant définit une classe qui contient des données et une logique d'application, et est associée à un modèle HTML qui définit une vue à afficher dans un environnement cible. Le décorateur `@Component()` identifie la classe immédiatement en dessous comme un composant, et fournit le modèle et les métadonnées spécifiques au composant. Le `AppComponent` est défini dans le fichier `app.component.ts`.
Les NgModules Angular déclarent un contexte de compilation pour un ensemble de composants qui est dédié à un domaine d'application, un flux de travail, ou un ensemble de capacités étroitement liées. Chaque application Angular a un module racine, conventionnellement nommé `AppModule`, qui fournit le mécanisme de démarrage qui lance l'application. Une application contient généralement de nombreux modules fonctionnels. Le `AppModule` est défini dans le fichier `app.module.ts`.
Le NgModule `Router` d'Angular fournit un service qui vous permet de définir un chemin de navigation parmi les différents états d'application et hiérarchies de vues dans votre application. Le `RouterModule` est défini dans le fichier `app-routing.module.ts`.
Pour les données ou la logique qui ne sont pas associées à une vue spécifique, et que vous souhaitez partager entre les composants, vous créez une classe de service. La définition d'une classe de service est immédiatement précédée du décorateur `@Injectable()`. Le décorateur fournit les métadonnées qui permettent à d'autres fournisseurs d'être injectés en tant que dépendances dans votre classe. L'injection de dépendance (DI) vous permet de garder vos classes de composants légères et efficaces. Elles ne récupèrent pas de données du serveur, ne valident pas les entrées utilisateur, ou ne se connectent pas directement à la console ; elles délèguent de telles tâches aux services.
## Configuration de sourcemap
Le framework Angular traduit les fichiers TypeScript en code JavaScript en suivant les options de `tsconfig.json` et construit ensuite un projet avec la configuration `angular.json`. En regardant le fichier `angular.json`, nous avons observé une option pour activer ou désactiver un sourcemap. Selon la documentation Angular, la configuration par défaut a un fichier sourcemap activé pour les scripts et n'est pas caché par défaut :
```json
"sourceMap": {
"scripts": true,
"styles": true,
"vendor": false,
"hidden": false
}
```
Généralement, les fichiers sourcemap sont utilisés à des fins de débogage car ils associent les fichiers générés à leurs fichiers d'origine. Par conséquent, il n'est pas recommandé de les utiliser dans un environnement de production. Si les sourcemaps sont activés, cela améliore la lisibilité et aide à l'analyse des fichiers en reproduisant l'état d'origine du projet Angular. Cependant, s'ils sont désactivés, un examinateur peut toujours analyser manuellement un fichier JavaScript compilé en recherchant des motifs anti-sécurité.
De plus, un fichier JavaScript compilé avec un projet Angular peut être trouvé dans les outils de développement du navigateur → Sources (ou Débogueur et Sources) → \[id].main.js. Selon les options activées, ce fichier peut contenir la ligne suivante à la fin `//# sourceMappingURL=[id].main.js.map` ou il peut ne pas l'avoir, si l'option **hidden** est définie sur **true**. Néanmoins, si le sourcemap est désactivé pour **scripts**, les tests deviennent plus complexes, et nous ne pouvons pas obtenir le fichier. De plus, le sourcemap peut être activé lors de la construction du projet comme `ng build --source-map`.
## Liaison de données
La liaison fait référence au processus de communication entre un composant et sa vue correspondante. Elle est utilisée pour transférer des données vers et depuis le framework Angular. Les données peuvent être transmises par divers moyens, tels que par le biais d'événements, d'interpolation, de propriétés ou par le mécanisme de liaison bidirectionnelle. De plus, les données peuvent également être partagées entre des composants liés (relation parent-enfant) et entre deux composants non liés en utilisant la fonctionnalité Service.
Nous pouvons classer la liaison par flux de données :
* Source de données vers cible de vue (inclut _interpolation_, _propriétés_, _attributs_, _classes_ et _styles_); peut être appliqué en utilisant `[]` ou `{{}}` dans le modèle ;
* Cible de vue vers source de données (inclut _événements_); peut être appliqué en utilisant `()` dans le modèle ;
* Bidirectionnelle ; peut être appliqué en utilisant `[()]` dans le modèle.
La liaison peut être appelée sur des propriétés, des événements et des attributs, ainsi que sur tout membre public d'une directive source :
| TYPE | CIBLE | EXEMPLES |
| --------- | -------------------------------------------------------- | -------------------------------------------------------------------- |
| Propriété | Propriété d'élément, Propriété de composant, Propriété de directive | \ |
| Événement | Événement d'élément, Événement de composant, Événement de directive | \