1 00:00:01,150 --> 00:00:07,410 Welcome to a course on Application Security the course will highlight the features and characteristics 2 00:00:07,410 --> 00:00:12,690 of both secure and insecure applications and examine the most widespread types of application layer 3 00:00:12,690 --> 00:00:13,550 attacks. 4 00:00:18,480 --> 00:00:24,120 To start off a secure application is an application that above all must be able to deal with atypical 5 00:00:24,240 --> 00:00:26,230 unexpected or incorrect input. 6 00:00:26,250 --> 00:00:35,900 Efficiently the most common types of attacks including buffer overflow as fuel injection or HMO cross-site 7 00:00:35,900 --> 00:00:44,830 scripting rely on the insecure input handling of non-typical incorrect or specially crafted input. 8 00:00:44,830 --> 00:00:46,540 How did this problem come about. 9 00:00:48,420 --> 00:00:55,550 The picture above is an illustration of an obviously great construction achievement erecting the bridge 10 00:00:55,550 --> 00:01:01,280 do not only require detailed planning but also putting the plans into action. 11 00:01:01,330 --> 00:01:06,930 It requires the ability to predict all possible scenarios and circumstances and potential problems. 12 00:01:09,510 --> 00:01:13,130 The result is an impressive bridge that feels and is safe. 13 00:01:14,270 --> 00:01:21,410 What it means for us is that creating safe solutions is possible regardless of scale. 14 00:01:21,410 --> 00:01:27,320 Unfortunately though constructing a faultless bridge even as large as the one in the picture is less 15 00:01:27,320 --> 00:01:29,810 demanding than writing a secure application. 16 00:01:31,750 --> 00:01:35,580 It's easy to foresee the external threats a bridge will come up against in its use. 17 00:01:36,690 --> 00:01:43,880 It's wind and water the factors can be provided for during design and the completed design will only 18 00:01:43,880 --> 00:01:51,300 need to be followed exactly applications on the other hand have to be immune against unforseen factors 19 00:01:51,300 --> 00:01:59,080 and threats against unexpected exploitation attempts launched by knowledgeable attackers. 20 00:01:59,100 --> 00:02:01,590 The scale of the problem is altogether different. 21 00:02:02,780 --> 00:02:07,910 We could write an application that doesn't act up if all allowed input would be in the specified range 22 00:02:08,150 --> 00:02:12,310 or would be valid creating an application that is secure. 23 00:02:12,310 --> 00:02:14,070 Per se is far less easy 24 00:02:19,910 --> 00:02:24,630 a secure applications default settings should be at once the safest options. 25 00:02:26,290 --> 00:02:31,270 The rationale for this is that the majority of users don't change the configuration after they've installed 26 00:02:31,270 --> 00:02:32,250 an application 27 00:02:34,850 --> 00:02:39,170 especially features that aren't used on a daily basis will rarely be disabled. 28 00:02:41,550 --> 00:02:46,400 If the features aren't being used or worked with this usually means that a user is not aware of them 29 00:02:48,410 --> 00:02:51,370 disabling features that you don't know exist is rather tricky 30 00:02:54,400 --> 00:02:57,930 if an applications default configuration is the most functional. 31 00:02:58,070 --> 00:03:04,800 You face the risk that it would run in a much wider range than the tasks it's usually made to in the 32 00:03:04,800 --> 00:03:07,470 range you can't see is the range you can't protect 33 00:03:13,040 --> 00:03:18,260 a secure application is an application that doesn't need escalated or superfluous permissions to run 34 00:03:21,430 --> 00:03:24,460 administrative permissions in particular should not be required 35 00:03:27,210 --> 00:03:34,450 these rules are the principle of least privilege and the principle of minimising attack surface areas. 36 00:03:34,540 --> 00:03:37,690 They both work to reduce fallout from a potential attack. 37 00:03:39,770 --> 00:03:45,110 If an application runs under a standard user's permissions all changes that can be made will only apply 38 00:03:45,110 --> 00:03:49,060 to the user's session. 39 00:03:49,090 --> 00:03:53,870 The next step will be to adopt a model that is popular in the line X in Unix environments. 40 00:03:55,310 --> 00:03:57,210 Escalated permissions are not necessary. 41 00:03:57,200 --> 00:04:03,510 There are not only to run an application but also to install it an application would be installed per 42 00:04:03,510 --> 00:04:07,000 user and the user would be held responsible for it. 43 00:04:13,940 --> 00:04:19,810 Carnegie-Mellon research shows that for every 10000 lines of code there are from 15 to 30 programming 44 00:04:19,810 --> 00:04:28,550 bugs about 5 percent of the bugs are security critical affecting the security of the application or 45 00:04:28,550 --> 00:04:31,330 indirectly the security of the system in users. 46 00:04:35,050 --> 00:04:42,200 This means that if a program contains 10 million lines of code it will have 20000 bugs on average a 47 00:04:42,440 --> 00:04:46,880 thousand of them may have a bearing on the application security. 48 00:04:46,900 --> 00:04:49,390 That's quite a large number. 49 00:04:49,580 --> 00:04:57,040 If we were able to create a truly secure application it would have to be flawless as you can see though 50 00:04:57,070 --> 00:05:01,430 this is nearly impossible. 51 00:05:01,670 --> 00:05:07,800 If an attacker spots and exploits just one of the thousand vulnerabilities they'll take over the application. 52 00:05:08,840 --> 00:05:13,630 Of course this depends on the permissions that it runs under and how critical the bug was. 53 00:05:16,110 --> 00:05:22,810 Application Security is especially vital in view of the fact that in 2005 the number of detected system 54 00:05:22,810 --> 00:05:30,850 holes the bugs that are security critical dropped lower than 10 percent of all identified vulnerabilities. 55 00:05:30,850 --> 00:05:38,050 This means that application bugs account for 90 percent of all vulnerabilities administrators and users 56 00:05:38,320 --> 00:05:44,660 possibly out of habit usually spend most of their time on protecting operating systems. 57 00:05:44,690 --> 00:05:49,400 It can be said that 90 percent of an administrator's working hours are spent on eliminating threats 58 00:05:49,400 --> 00:05:52,710 that are less than 10 percent of all applicable hazards. 59 00:05:59,490 --> 00:06:04,950 What makes things even worse is the application layer attacks succeed regardless of any security solutions 60 00:06:04,950 --> 00:06:07,730 implemented in the system or network layers. 61 00:06:10,270 --> 00:06:16,930 Detects don't modify network packages in ways that are not provided for by protocols they don't scan 62 00:06:16,930 --> 00:06:19,450 any ports. 63 00:06:19,470 --> 00:06:23,190 That's why firewalls and intrusion detection systems are easy to bypass 64 00:06:26,810 --> 00:06:31,350 an application attack is indistinguishable from normal usage for a computer network. 65 00:06:34,310 --> 00:06:40,580 Apart from that an application is run directly by a user and since as a user who's run it a system can't 66 00:06:40,580 --> 00:06:45,220 disable it from performing any operations. 67 00:06:45,270 --> 00:06:49,530 It was the users informed decision to run the program. 68 00:06:49,590 --> 00:06:50,880 The system will not control it. 69 00:06:50,880 --> 00:06:55,890 From then on we're ignoring the solutions that are less popular today. 70 00:06:56,840 --> 00:07:04,280 Like permissions that are granted to code or application and not to user in a context of a user session 71 00:07:04,580 --> 00:07:06,740 and application is free to do anything. 72 00:07:08,400 --> 00:07:18,840 Well try to answer some interesting questions in this module. 73 00:07:18,860 --> 00:07:22,260 What's the typical schema for a buffer overflow attack. 74 00:07:22,280 --> 00:07:27,680 Why is modifying or controlling program execution possible without modifying the program's source code. 75 00:07:32,070 --> 00:07:40,460 Why our database is vulnerable to ESC fuel injection as CULE query manipulation attacks. 76 00:07:40,510 --> 00:07:44,410 Can these database servers and database application attacks be automated. 77 00:07:47,360 --> 00:07:52,430 Why does a cross-site scripting attack target the pages visitors and not the web page itself. 78 00:07:54,670 --> 00:08:01,310 How can an attacker impersonate an authenticated user of a web application. 79 00:08:01,400 --> 00:08:06,960 Finally we'll try to see if there's some way to prevent users from running insecure or harmful programs. 80 00:08:09,030 --> 00:08:14,850 We'll also discuss the features and characteristics of insecure programs. 81 00:08:14,870 --> 00:08:15,950 See you in the training.