Différences

Ci-dessous, les différences entre deux révisions de la page.

--- en:cs:web_applications_threats_modeling [2017/01/27 14:18] – [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 =====
-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 parameters being in forms, URL parameters, ... called $ \mathcal{P} = \{p_{1},\dots,p_{n}\}, \, n \in \mathbb{N} $.\\
-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: the HTTP protocol only transport text. But we might consider the langage associated to each parameters $ p_{i} $ to ease the future data injection.
-$ \mathcal{T} =
-   \left \{
-   \begin{array}{r c l}
-      t_{1}  & = & integer \\
-      t_{2}  & = & string \\
-      \vdots & & \vdots \\
-      t_{k}  & = & type_{k}
-   \end{array}
-   \right . \quad k \in \mathbb{N}. $
-We will consider the cartesian product $ \mathcal{I}\times\matchcal{T} $ in the future.
+We will consider the set $ \mathcal{P} $ in the future.
-__Question:__ Does it matter if it's a form input or an URL parameter or ... ?
+__Question:__ Does it matter if it's a form input parameter or an URL parameter or ... ?
 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 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' type shall be inferred.
-We might also consider the location of each input.\\
-__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},\dots,l_{p}\}, \, p \in \mathbb{N}$  where  $l_{i}$  is the location of  $i_{i}$  which might not be unique !)
-  * Phase two: determine data pattern to inject
+We might also consider the location of each parameters.\\
+__Question__: When the location information of parameters will be useful ?\\
+(If it's useful, it will bring in a new finite set  $\mathcal{L}$  which will contain  $\{l_{1},\dots,l_{p}\}, \, p \in \mathbb{N}$  where  $l_{i}$  is the location of  $p_{i}$  which might not be unique !)
-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. The building of the set of data patterns is challenging.\\
+  * Phase two: determine data pattern to inject
-For now, will only know it is finite.
-One way to build it is to start with an alphabet and some syntactic rules to combine each elements if the alphabet.
+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.
-  * Phase three: inject sensibly the data patterns in all inputs
+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.
+  * Phase three: inject sensibly the data patterns in all visible parameters
+Inject.