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:09] – [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 inputs | + | Each web applications has a finite set of visibles |
| - | All inputs | + | 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 | + | Let's describe the processus to assess A1 threats |
| - | * 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, | + | If it's a black box testing, it will be based on URLs 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 input type shall be inferred. | + | In case of code static analysis, each visible parameters' |
| + | |||
| + | We might also consider the location of each parameters.\\ | ||
| + | __Question__: | ||
| + | (If it's useful, it will bring in a new finite set $ \mathcal{L} $ which will contain $ \{l_{1}, | ||
| + | |||
| + | * Phase two: determine data pattern to inject | ||
| + | |||
| + | It will of course not be a blind and random data building like fuzzing, data should be carefully crafted depending on the parameters langage and probably location. The building of the set of data patterns is challenging.\\ | ||
| + | For now, we only know it is finite. | ||
| - | We might also consider | + | One way to build it is to start with an alphabet and some syntactic rules to combine each element in the alphabet in a meaningful fashion for security. |
| - | __Question__: When the location information of inputs will be useful ?\\ | + | |
| - | (If it's useful, it will bring in a new finite set $ \mathcal{L} $ which will contain $ \{l_{1}, | + | * Phase three: inject sensibly |
| - | * Phase two: determine data pattern to inject: | + | Inject. |
| - | It will of course not be a blind and random data building like fuzzing, data should be intelligently crafted depending on the inputs type and probably location. | + | |