1
00:00:00,090 --> 00:00:06,780
As a starting point for the discussion of input validation, I will base the discussion on OWASP

2
00:00:06,780 --> 00:00:08,700
secure coding guidelines.

3
00:00:10,940 --> 00:00:18,470
First of all, it is necessary to understand what the possible input channels are for a Web application

4
00:00:18,950 --> 00:00:26,900
in this slide, I highlighted the various possibilities with which a Web application can receive data

5
00:00:26,900 --> 00:00:35,240
inputs, because it is important that validation takes place on all possible input channels.

6
00:00:37,510 --> 00:00:46,630
The validation must include a phase of canonicalization of the data before validating them or returning

7
00:00:46,630 --> 00:00:55,480
data to a standard format to avoid validation by-pass with transcoding techniques. The validation must

8
00:00:55,480 --> 00:01:04,060
verify that the input data respect the expected format in terms of size, data type, range.

9
00:01:06,610 --> 00:01:15,880
For the search for input characters that underlie particular types of attack, it is always better

10
00:01:16,000 --> 00:01:23,890
to reason from a white list of allowed characters rather than a blacklist of illegal characters.

11
00:01:24,310 --> 00:01:32,680
Also prefer the mechanism of regular expressions for the validation of input. In addition, to validating

12
00:01:32,680 --> 00:01:34,880
the input of Web applications

13
00:01:35,140 --> 00:01:42,970
It is also important to make sure that the output of the application does not cause damage to third

14
00:01:42,970 --> 00:01:51,340
parties, such as the database with which the server side application dialogues or web clients through

15
00:01:51,340 --> 00:01:52,300
responses.

16
00:01:54,740 --> 00:02:02,800
The lack of adequate input validation is the cause of a huge variety of possible types of attacks,

17
00:02:03,400 --> 00:02:06,850
of which the slide provides a list.

18
00:02:09,370 --> 00:02:12,150
Thank you for your kind attention.