Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
en:cs:web_applications_threats_modeling [2017/01/27 14:45] – [Threats class: A1 injection] fraggle | en:cs:web_applications_threats_modeling [2021/12/27 18:25] (Version actuelle) – modification externe 127.0.0.1 | ||
---|---|---|---|
Ligne 8: | Ligne 8: | ||
===== Threats class: A1 injection ===== | ===== Threats class: A1 injection ===== | ||
- | Each web applications has a finite set of input parameters being in forms, URL parameters, ... called $ \mathcal{I} = \{i_{1},\dots,i_{n}\}, \, n \in \mathbb{N} $.\\ | + | Each web applications has a finite set of visibles |
- | All input parameters are typed: $ i_{1} \, {\longmapsto} \, t_{3}; \dots ; \, i_{n} \, {\longmapsto} \, t_{7}, \, t_{i} $ being chosen in a finite set of type called | + | All parameters are not typed: |
- | + | ||
- | $ \mathcal{T} = | + | |
- | | + | |
- | | + | |
- | t_{1} & = & integer \\ | + | |
- | t_{2} & = & string \\ | + | |
- | \vdots & & \vdots \\ | + | |
- | t_{k} & = & type_{k} | + | |
- | | + | |
- | | + | |
- | We will consider the cartesian product | + | We will consider the set $ \mathcal{P} $ in the future. |
- | __Question: | + | __Question: |
Let's describe the processus to assess A1 threats in a web application. | Let's describe the processus to assess A1 threats in a web application. | ||
- | * Phase one: determine $ \mathcal{I}\times\matchcal{T} $ | + | * Phase one: determine $ \mathcal{P} $ |
- | It will be depend on the approach chosen.\\ | + | It will depend on the approach chosen.\\ |
If it's a black box testing, it will be based on URLs scanning, pages content scanning, ....\\ | If it's a black box testing, it will be based on URLs scanning, pages content scanning, ....\\ | ||
If it's static code analysis, it will be based on detection of code pattern.\\ | If it's static code analysis, it will be based on detection of code pattern.\\ | ||
- | Each inputs' type shall be inferred. | + | In case of code static analysis, each visible parameters' type shall be inferred. |
- | We might also consider the location of each input.\\ | + | We might also consider the location of each parameters.\\ |
- | __Question__: | + | __Question__: |
- | (If it's useful, it will bring in a new finite set L which will contain {l1,…,lp},p∈N where li is the location of $ i_{i} $ which might not be unique !) | + | (If it's useful, it will bring in a new finite set L which will contain {l1,…,lp},p∈N where li is the location of $ p_{i} $ which might not be unique !) |
* Phase two: determine data pattern to inject | * Phase two: determine data pattern to inject | ||
- | It will of course not be a blind and random data building like fuzzing, data should be intelligently | + | It will of course not be a blind and random data building like fuzzing, data should be carefully |
For now, we only know it is finite. | For now, we only know it is finite. | ||
- | One way to build it is to start with an alphabet and some syntactic rules to combine each elements | + | One way to build it is to start with an alphabet and some syntactic rules to combine each element |
- | * Phase three: inject sensibly the data patterns in all inputs | + | * Phase three: inject sensibly the data patterns in all visible parameters |
Inject. | Inject. |