SlideShare a Scribd company logo

Security testing

•Download as PPTX, PDF•
•
Khizra Sammad
Khizra Sammad

Security Testing is a process to determine that an information system protects data and maintains functionality as intended.

Related slideshows

Penetration testing & Ethical Hacking
Penetration testing & Ethical HackingPenetration testing & Ethical Hacking
Penetration testing & Ethical Hacking
 
Introduction To Vulnerability Assessment & Penetration Testing
Introduction To Vulnerability Assessment & Penetration TestingIntroduction To Vulnerability Assessment & Penetration Testing
Introduction To Vulnerability Assessment & Penetration Testing
 
Top 10 Web Security Vulnerabilities (OWASP Top 10)
Top 10 Web Security Vulnerabilities (OWASP Top 10)Top 10 Web Security Vulnerabilities (OWASP Top 10)
Top 10 Web Security Vulnerabilities (OWASP Top 10)
 
1 of 46
Security Testing Author : Khizra Abdul Sammad
Security Testing is a process to determine that an information system protects data and maintains functionality as intended.
Purpose of Security Testing • Primary purpose of security testing is to identify the vulnerabilities and subsequently repairing them. • Finding out loopholes that can cause loss of important information and allow any intruder enter into the system. • Improving the current system and also ensuring that the system will work for longer time. • Ensuring that people in your organization understand and obey security policies.
Security Testing Techniques Main security testing techniques are: • Vulnerability Scanning • Security Scanning • Penetration Testing • Ethical Hacking • Risk Assessment • Security Auditing • Posture Assessment & Security Testing • Password cracking • cross-site scripting • cross-site request forgery (XSRF).
Vulnerability Scanning • It involves scanning of the application for all known vulnerabilities. • A computer program designed to assess computers, computer systems, networks or applications for weaknesses. • Generally done through various vulnerability scanning software. Ex : Nessus, Sara, and ISS. Security Scanning • Scanning and verification of the system and applications. • Find out the weaknesses in the OS, applications and networks. Cont..
Penetration Testing • Tester may try to enter into the application / system with the help of some other application or with the help of combinations of loopholes that the application has kept open unknowingly. • It is the most effective way to practically find out potential loopholes in the application. Ethical Hacking Ethical Hacking involves number of penetration tests over the wide network on the system under test. It is conducted by ethical hackers to find possible problems in the system. Cont..
Risk Assessment • Is a method of analyzing and deciding the risk that depends upon the type of loss and the possibility / probability of loss occurrence. • Risk assessment is carried out in the form of various interviews, discussions and analysis of the same. Security Auditing • Security Auditing involves hands on internal inspection of Operating Systems and Applications, often via line-by-line inspection of the code. • A security audit is a systematic evaluation of the security of a company's information system. Cont..
Posture Assessment and Security Testing • It combines Security Scanning, Ethical Hacking and Risk Assessments to show an overall Security Posture of the organization. Password Cracking • Password cracking programs can be used to identify weak passwords. • Password cracking verifies that users are employing sufficiently strong passwords. Cont..
Cross-site scripting (XSS) Enables attackers to inject client-side script into Web pages viewed by other users. Non-Persistent XSS Attack Attack requires a user to visit the specially crafted link by the attacker. When the user visit the link, the crafted code will get executed by the user’s browser. Persistent XSS Attack •Code injected by the attacker will be stored in a secondary storage device (mostly on a database). •The damage caused by Persistent attack is more than the non-persistent attack. Cont..
Gruyere Setup • To access Gruyere, go to http://google- gruyere.appspot.com/start. • AppEngine will start a new instance of Gruyere and assign it a unique id and redirect you to http://google- gruyere.appspot.com/123/ (where 123 is your unique id). • • Each instance of Gruyere is "sandboxed" from the other instances so your instance won't be affected by anyone else using Gruyere.
Features and Technologies Gruyere includes a number of special features and technologies which add attack surface. Each of these introduces new vulnerabilities. 1. HTML in Snippets: Users can include a limited subset of HTML in their snippets. 2. File upload: Users can upload files to the server, e.g., to include pictures in their snippets. 3. Web administration: System administrators can manage the system using a web interface. 4. New accounts: Users can create their own accounts.
5. Template language: Gruyere Template Language(GTL) is a new language that makes writing web pages easy as the templates connect directly to the database. Documentation for GTL can be found in gruyere/gtl.py. 6. AJAX: Gruyere uses AJAX to implement refresh on the home and snippets page. You should ignore the AJAX parts of Gruyere except for the challenges that specifically tell you to focus on AJAX. Cont..
• In a real application, refresh would probably happen automatically, but in Gruyere we've made it manual so that you can be in complete control while you are working with it. When you click the refresh link, Gruyere fetches feed.gtl which contains refresh data for the current page and then client-side script uses the browser DOM API (Document Object Model) to insert the new snippets into the page. Since AJAX runs code on the client side, this script is visible to attackers who do not have access to your source code. Cont..
Using Gruyere To familiarize yourself with the features of Gruyere, complete the following tasks: • View another user's snippets by following the "All snippets" link on the main page. Also check out what they have their Homepage set to. • Sign up for an account for yourself to use when hacking. Do not use the same password for your Gruyere account as you use for any real service.
• Fill in your account's profile, including a private snippet and an icon that will be displayed by your name. • Create a snippet (via "New Snippet") containing your favorite joke. • Upload a file (via "Upload") to your account. Cont..
Web Application Exploits and Defenses • Cross-Site Scripting (XSS) • Reflected XSS Attack
Cross-Site Scripting (XSS) • Cross-site scripting (XSS) is a vulnerability that permits an attacker to inject code (typically HTML or Javascript) into contents of a website not under the attacker's control. When a victim views such a page, the injected code executes in the victim's browser. Thus, the attacker has bypassed the browser's same origin policy and can steal victim's private information associated with the website in question. Cont..
Reflected XSS • In a reflected XSS attack, the attack is in the request itself (frequently the URL) and the vulnerability occurs when the server inserts the attack in the response verbatim or incorrectly escaped or sanitized. The victim triggers the attack by browsing to a malicious URL created by the attacker. Cont..
• XSS is a difficult beast. On one hand, a fix to an XSS vulnerability is usually trivial and involves applying the correct sanitizing function to user input when it's displayed in a certain context. On the other hand, if history is any indication, this is extremely difficult to get right. Cont..
Following Steps should be taken to prevent bugs of XSS vulnerabilities: 1. First, make sure you understand the problem. 2. Wherever possible, do sanitizing via templates features instead of calling escaping functions in source code. This way, all of your escaping is done in one place and your product can benefit from security technologies designed for template systems that verify their correctness or actually do the escaping for you. Also, familiarize yourself with the other security features of your template system. 3. Employ good testing practices with respect to XSS. 4. Don't write your own template library. Cont..
Client-State Manipulation • When a user interacts with a web application, they do it indirectly through a browser. When the user clicks a button or submits a form, the browser sends a request back to the web server. Because the browser runs on a machine that can be controlled by an attacker, the application must not trust any data sent by the browser. • If the user submits a form that says they wish to purchase an item, it's OK to trust that data. But if the submitted form also includes the price of the item, that's something that cannot be trusted.
Exploit and Fix 1. You can convert your account to being an administrator by issuing either of the following requests: 2. http://google- gruyere.appspot.com/123/saveprofile?action=updat e&is_admin=True 3. http://google- gruyere.appspot.com/123/saveprofile?action=updat e&is_admin=True&uid=username (which will make anyusername into an an admin) Cont..
4. After visiting this URL, your account is now marked as an administrator but your cookie still says you're not. So sign out and back in to get a new cookie. After logging in, notice the 'Manage this server' link on the top right. 5. The bug here is that there is no validation on the server side that the request is authorized. The only part of the code that restricts the changes that a user is allowed to make are in the template, hiding parts of the UI that they shouldn't have access to. The correct thing to do is to check for authorization on the server, at the time that the request is received. Cont..
Exapmle Suppose Blogger is vulnerable to XSRF attacks (it isn't). And let us say Blogger has a Delete Blog button on the dashboard that points to this URL: http://www.blogger.com/deleteblog.do?blogId=BL OGID • Bob, the attacker, embeds the following HTML on his web page on http://www.evil.example.com: • <img src="http://www.blogger.com/deleteblog.do?blo gId=alice's-blog-id" style="display:none"> Cont..
If the victim, Alice, is logged in to www.blogger.com when she views the above page, here is what happens: 1. Her browser loads the page from http://www.evil.example.com. The browser then tries to load all embedded objects in the page, including the img shown above. 2. The browser makes a request to http://www.blogger.com/deleteblog.do?blogId= alice's-blog-id to load the image. Since Alice is logged into Blogger — that is, she has a Blogger cookie — the browser also sends that cookie in the request. Cont..
1. Blogger verifies the cookie is a valid session cookie for Alice. It verifies that the blog referenced by alice's-blog-id is owned by Alice. It deletes Alice's blog. 2. Alice has no idea what hit her. • In this sample attack, since each user has their own blog id, the attack has to be specifically targeted to a single person. In many cases, though, requests like these don't contain any user-specific data. Cont..
Path Traversal--4 • Most web applications serve static resources like images and CSS files. Frequently, applications simply serve all the files in a folder. • If the application isn't careful, the user can use a path traversal attack to read files from other folders that they shouldn't have access to. For example, in both Windows and Linux, .. represents the parent directory, so if you can inject ../ in a path you can "escape" to the parent directory.
• If an attacker knows the structure of your file system, then they can craft a URL that will traverse out of the installation directory to /etc. • For example, if Picasa was vulnerable to path traversal (it isn't) and the Picasa servers use a Unix-like system, then the following would retrieve the password file: • http://www.picasa.com/../../../../../../../etc/passwd Cont..
• this attack is not even necessary in many cases: people often install applications and never change the defaults. So the first thing an attacker would try is the default value • This isn't a black box attack because you need to know that the secret.txt file exists, where it's stored, and where Gruyere stores its resource files. You don't need to look at any source code. Cont..
Denial of Service • A denial of service (DoS) attack is an attempt to make a server unable to service ordinary requests. • A common form of DoS attack is sending more requests to a server than it can handle. • The server spends all its time servicing the attacker's requests that it has very little time to service legitimate requests. Protecting an application against these kinds of DoS attacks is outside the scope of this codelab. And attacking Gruyere in this way would be interpreted as an attack on App Engine.
• Hackers can also prevent a server from servicing requests by taking advantage of server bugs, such as sending requests that crash a server, make it run out of memory, or otherwise cause it fail serving legitimate requests in some way. In the next few challenges, you'll take advantage of bugs in Gruyere to perform DoS attacks. Cont..
DoS - Quit the Server • The simplest form of denial of service is shutting down a service.
Exploit and Fix • To exploit, make a request to http://google- gruyere.appspot.com/123/quitserver. • You should need to be logged in as an administrator to do this, but you don't. • This is another example of a common bug. The server protects against non-administrators accessing certain URLs but the list includes /quit instead of the actual URL /quitserver. Cont..
• To fix, add /quitserver to the URLS only accessible to administrators: • _PROTECTED_URLS = [ "/quitserver", "/reset" • This doesn't completely solve the problem. • The reset URL is in the protected list. • To fix, put the security check inside the dangerous functions rather than outside them. That ensures that no matter how we get there, the security check can't be skipped. Cont..
DoS - Overloading the Server • You can upload a template that does this. Exploit and Fix • To exploit, create a file named menubar.gtl containing: [[include:menubar.gtl]]DoS[[/include:menubar.gtl]] and upload it to the resources directory using a path traversal attack, e.g., creating a user named ../resources. • To fix, implement the protections against path traversal and uploading templates discussed earlier. • NOTE: After performing the previous exploit, you'll need to push the reset button.
Code Execution • If an attacker can execute arbitrary code remotely on your server, it's usually game over. They may be able to take control over the running program or potentially break out the process to open a new shell on the computer. From here, it's usually not hard to compromise the entire machine the server is running on.
• Similar to information disclosure and denial of service, there is no recipe or specific defense to prevent remote code execution. • The program must perform validation of all user input before handling it and where possible, implement functions with least privilege rights. This topic can't be done justice in just a short paragraph, but know that this is likely the scariest results a security bug can have and trumps any of the above attacks. Cont..
Even though there is no single or simple defense to remote code execution, here is a short list of some preventative measures: • Least Privilege: Always run your application with the least privileges it needs. • Application Level Checks: Avoid passing user input directly into commands that evaluate arbitrary code, like eval() or system(). Instead, use the user input as a switch to choose from a set of developer controlled commands. • Bounds Checks: Implement proper bounds checks for non- safe languages like C++. Avoid unsafe string functions. Keep in mind that even safe languages like Python and Java use native libraries. Preventative measures
Configuration Vulnerabilities • Applications are often installed with default settings that attackers can use to attack them. This is particularly an issue with third party software where an attacker has easy access to a copy of the same application or framework you are running. Hackers know the default account names and passwords. • For example, looking at the contents of data.py you know that there's a default administrator account named 'admin' with the password 'secret'.
• Configuration vulnerabilities also include features that increase attack surface. A common example is a feature that is on by default but you are not using, so you didn't configure it and the default configuration is vulnerable. It also includes debug features like status pages or dumping stack traces on failures. Cont..
AJAX vulnerabilities • Bad AJAX code allows attackers to modify parts of your application in ways that you might not expect. In traditional client development, there is a clear separation between the application and the data it displays
• To exploit, create a user named private_snippet and create at least one snippet. • The JSON response will then be {'private_snippet' : <user's private snippet>, ..., 'private_snippet' : <attacker's snippet>} and the attacker's snippet replaces the user's. • To fix, the AJAX code needs to make sure that the data only goes where it's supposed to go. • The flaw here is that the JSON structure is not robust. A better structure would be[<private_snippet>, {<user> : <snippet>,...}]. Cont..
Other Vulnerabilities • Buffer Overflow • Integer Overflow
Buffer Overflow A buffer overflow vulnerability exists when an application does not properly guard its buffers and allow user data to write past the end of a buffer. • This excess data can modify other variables, including pointers and function return addresses, leading to arbitrary code execution. • Historically, buffer overflow vulnerabilities have been responsible for some of the most widespread internet attacks including SQL Slammer, Blaster and Code Red computer worms. The PS2, Xbox and Wii have all been hacked using buffer overflow exploits. Cont..
Integer Overflow • integer overflow vulnerabilities can be just as dangerous. Any time an integer computation silently returns an incorrect result, the application will operate incorrectly. • In the best case, the application fails. In the worst case, there is a security bug. For example, if an application checks that length + 1 < limit then this will succeed if length is the largest positive integer value, which can then expose a buffer overflow vulnerability. Cont..
Thank You

More Related Content

Security testing

  • 1. Security Testing Author : Khizra Abdul Sammad
  • 2. Security Testing is a process to determine that an information system protects data and maintains functionality as intended.
  • 3. Purpose of Security Testing • Primary purpose of security testing is to identify the vulnerabilities and subsequently repairing them. • Finding out loopholes that can cause loss of important information and allow any intruder enter into the system. • Improving the current system and also ensuring that the system will work for longer time. • Ensuring that people in your organization understand and obey security policies.
  • 4. Security Testing Techniques Main security testing techniques are: • Vulnerability Scanning • Security Scanning • Penetration Testing • Ethical Hacking • Risk Assessment • Security Auditing • Posture Assessment & Security Testing • Password cracking • cross-site scripting • cross-site request forgery (XSRF).
  • 5. Vulnerability Scanning • It involves scanning of the application for all known vulnerabilities. • A computer program designed to assess computers, computer systems, networks or applications for weaknesses. • Generally done through various vulnerability scanning software. Ex : Nessus, Sara, and ISS. Security Scanning • Scanning and verification of the system and applications. • Find out the weaknesses in the OS, applications and networks. Cont..
  • 6. Penetration Testing • Tester may try to enter into the application / system with the help of some other application or with the help of combinations of loopholes that the application has kept open unknowingly. • It is the most effective way to practically find out potential loopholes in the application. Ethical Hacking Ethical Hacking involves number of penetration tests over the wide network on the system under test. It is conducted by ethical hackers to find possible problems in the system. Cont..
  • 7. Risk Assessment • Is a method of analyzing and deciding the risk that depends upon the type of loss and the possibility / probability of loss occurrence. • Risk assessment is carried out in the form of various interviews, discussions and analysis of the same. Security Auditing • Security Auditing involves hands on internal inspection of Operating Systems and Applications, often via line-by-line inspection of the code. • A security audit is a systematic evaluation of the security of a company's information system. Cont..
  • 8. Posture Assessment and Security Testing • It combines Security Scanning, Ethical Hacking and Risk Assessments to show an overall Security Posture of the organization. Password Cracking • Password cracking programs can be used to identify weak passwords. • Password cracking verifies that users are employing sufficiently strong passwords. Cont..
  • 9. Cross-site scripting (XSS) Enables attackers to inject client-side script into Web pages viewed by other users. Non-Persistent XSS Attack Attack requires a user to visit the specially crafted link by the attacker. When the user visit the link, the crafted code will get executed by the user’s browser. Persistent XSS Attack •Code injected by the attacker will be stored in a secondary storage device (mostly on a database). •The damage caused by Persistent attack is more than the non-persistent attack. Cont..
  • 10. Gruyere Setup • To access Gruyere, go to http://google- gruyere.appspot.com/start. • AppEngine will start a new instance of Gruyere and assign it a unique id and redirect you to http://google- gruyere.appspot.com/123/ (where 123 is your unique id). • • Each instance of Gruyere is "sandboxed" from the other instances so your instance won't be affected by anyone else using Gruyere.
  • 11. Features and Technologies Gruyere includes a number of special features and technologies which add attack surface. Each of these introduces new vulnerabilities. 1. HTML in Snippets: Users can include a limited subset of HTML in their snippets. 2. File upload: Users can upload files to the server, e.g., to include pictures in their snippets. 3. Web administration: System administrators can manage the system using a web interface. 4. New accounts: Users can create their own accounts.
  • 12. 5. Template language: Gruyere Template Language(GTL) is a new language that makes writing web pages easy as the templates connect directly to the database. Documentation for GTL can be found in gruyere/gtl.py. 6. AJAX: Gruyere uses AJAX to implement refresh on the home and snippets page. You should ignore the AJAX parts of Gruyere except for the challenges that specifically tell you to focus on AJAX. Cont..
  • 13. • In a real application, refresh would probably happen automatically, but in Gruyere we've made it manual so that you can be in complete control while you are working with it. When you click the refresh link, Gruyere fetches feed.gtl which contains refresh data for the current page and then client-side script uses the browser DOM API (Document Object Model) to insert the new snippets into the page. Since AJAX runs code on the client side, this script is visible to attackers who do not have access to your source code. Cont..
  • 14. Using Gruyere To familiarize yourself with the features of Gruyere, complete the following tasks: • View another user's snippets by following the "All snippets" link on the main page. Also check out what they have their Homepage set to. • Sign up for an account for yourself to use when hacking. Do not use the same password for your Gruyere account as you use for any real service.
  • 15. • Fill in your account's profile, including a private snippet and an icon that will be displayed by your name. • Create a snippet (via "New Snippet") containing your favorite joke. • Upload a file (via "Upload") to your account. Cont..
  • 16. Web Application Exploits and Defenses • Cross-Site Scripting (XSS) • Reflected XSS Attack
  • 17. Cross-Site Scripting (XSS) • Cross-site scripting (XSS) is a vulnerability that permits an attacker to inject code (typically HTML or Javascript) into contents of a website not under the attacker's control. When a victim views such a page, the injected code executes in the victim's browser. Thus, the attacker has bypassed the browser's same origin policy and can steal victim's private information associated with the website in question. Cont..
  • 18. Reflected XSS • In a reflected XSS attack, the attack is in the request itself (frequently the URL) and the vulnerability occurs when the server inserts the attack in the response verbatim or incorrectly escaped or sanitized. The victim triggers the attack by browsing to a malicious URL created by the attacker. Cont..
  • 19. • XSS is a difficult beast. On one hand, a fix to an XSS vulnerability is usually trivial and involves applying the correct sanitizing function to user input when it's displayed in a certain context. On the other hand, if history is any indication, this is extremely difficult to get right. Cont..
  • 20. Following Steps should be taken to prevent bugs of XSS vulnerabilities: 1. First, make sure you understand the problem. 2. Wherever possible, do sanitizing via templates features instead of calling escaping functions in source code. This way, all of your escaping is done in one place and your product can benefit from security technologies designed for template systems that verify their correctness or actually do the escaping for you. Also, familiarize yourself with the other security features of your template system. 3. Employ good testing practices with respect to XSS. 4. Don't write your own template library. Cont..
  • 21. Client-State Manipulation • When a user interacts with a web application, they do it indirectly through a browser. When the user clicks a button or submits a form, the browser sends a request back to the web server. Because the browser runs on a machine that can be controlled by an attacker, the application must not trust any data sent by the browser. • If the user submits a form that says they wish to purchase an item, it's OK to trust that data. But if the submitted form also includes the price of the item, that's something that cannot be trusted.
  • 22. Exploit and Fix 1. You can convert your account to being an administrator by issuing either of the following requests: 2. http://google- gruyere.appspot.com/123/saveprofile?action=updat e&is_admin=True 3. http://google- gruyere.appspot.com/123/saveprofile?action=updat e&is_admin=True&uid=username (which will make anyusername into an an admin) Cont..
  • 23. 4. After visiting this URL, your account is now marked as an administrator but your cookie still says you're not. So sign out and back in to get a new cookie. After logging in, notice the 'Manage this server' link on the top right. 5. The bug here is that there is no validation on the server side that the request is authorized. The only part of the code that restricts the changes that a user is allowed to make are in the template, hiding parts of the UI that they shouldn't have access to. The correct thing to do is to check for authorization on the server, at the time that the request is received. Cont..
  • 24. Exapmle Suppose Blogger is vulnerable to XSRF attacks (it isn't). And let us say Blogger has a Delete Blog button on the dashboard that points to this URL: http://www.blogger.com/deleteblog.do?blogId=BL OGID • Bob, the attacker, embeds the following HTML on his web page on http://www.evil.example.com: • <img src="http://www.blogger.com/deleteblog.do?blo gId=alice's-blog-id" style="display:none"> Cont..
  • 25. If the victim, Alice, is logged in to www.blogger.com when she views the above page, here is what happens: 1. Her browser loads the page from http://www.evil.example.com. The browser then tries to load all embedded objects in the page, including the img shown above. 2. The browser makes a request to http://www.blogger.com/deleteblog.do?blogId= alice's-blog-id to load the image. Since Alice is logged into Blogger — that is, she has a Blogger cookie — the browser also sends that cookie in the request. Cont..
  • 26. 1. Blogger verifies the cookie is a valid session cookie for Alice. It verifies that the blog referenced by alice's-blog-id is owned by Alice. It deletes Alice's blog. 2. Alice has no idea what hit her. • In this sample attack, since each user has their own blog id, the attack has to be specifically targeted to a single person. In many cases, though, requests like these don't contain any user-specific data. Cont..
  • 27. Path Traversal--4 • Most web applications serve static resources like images and CSS files. Frequently, applications simply serve all the files in a folder. • If the application isn't careful, the user can use a path traversal attack to read files from other folders that they shouldn't have access to. For example, in both Windows and Linux, .. represents the parent directory, so if you can inject ../ in a path you can "escape" to the parent directory.
  • 28. • If an attacker knows the structure of your file system, then they can craft a URL that will traverse out of the installation directory to /etc. • For example, if Picasa was vulnerable to path traversal (it isn't) and the Picasa servers use a Unix-like system, then the following would retrieve the password file: • http://www.picasa.com/../../../../../../../etc/passwd Cont..
  • 29. • this attack is not even necessary in many cases: people often install applications and never change the defaults. So the first thing an attacker would try is the default value • This isn't a black box attack because you need to know that the secret.txt file exists, where it's stored, and where Gruyere stores its resource files. You don't need to look at any source code. Cont..
  • 30. Denial of Service • A denial of service (DoS) attack is an attempt to make a server unable to service ordinary requests. • A common form of DoS attack is sending more requests to a server than it can handle. • The server spends all its time servicing the attacker's requests that it has very little time to service legitimate requests. Protecting an application against these kinds of DoS attacks is outside the scope of this codelab. And attacking Gruyere in this way would be interpreted as an attack on App Engine.
  • 31. • Hackers can also prevent a server from servicing requests by taking advantage of server bugs, such as sending requests that crash a server, make it run out of memory, or otherwise cause it fail serving legitimate requests in some way. In the next few challenges, you'll take advantage of bugs in Gruyere to perform DoS attacks. Cont..
  • 32. DoS - Quit the Server • The simplest form of denial of service is shutting down a service.
  • 33. Exploit and Fix • To exploit, make a request to http://google- gruyere.appspot.com/123/quitserver. • You should need to be logged in as an administrator to do this, but you don't. • This is another example of a common bug. The server protects against non-administrators accessing certain URLs but the list includes /quit instead of the actual URL /quitserver. Cont..
  • 34. • To fix, add /quitserver to the URLS only accessible to administrators: • _PROTECTED_URLS = [ "/quitserver", "/reset" • This doesn't completely solve the problem. • The reset URL is in the protected list. • To fix, put the security check inside the dangerous functions rather than outside them. That ensures that no matter how we get there, the security check can't be skipped. Cont..
  • 35. DoS - Overloading the Server • You can upload a template that does this. Exploit and Fix • To exploit, create a file named menubar.gtl containing: [[include:menubar.gtl]]DoS[[/include:menubar.gtl]] and upload it to the resources directory using a path traversal attack, e.g., creating a user named ../resources. • To fix, implement the protections against path traversal and uploading templates discussed earlier. • NOTE: After performing the previous exploit, you'll need to push the reset button.
  • 36. Code Execution • If an attacker can execute arbitrary code remotely on your server, it's usually game over. They may be able to take control over the running program or potentially break out the process to open a new shell on the computer. From here, it's usually not hard to compromise the entire machine the server is running on.
  • 37. • Similar to information disclosure and denial of service, there is no recipe or specific defense to prevent remote code execution. • The program must perform validation of all user input before handling it and where possible, implement functions with least privilege rights. This topic can't be done justice in just a short paragraph, but know that this is likely the scariest results a security bug can have and trumps any of the above attacks. Cont..
  • 38. Even though there is no single or simple defense to remote code execution, here is a short list of some preventative measures: • Least Privilege: Always run your application with the least privileges it needs. • Application Level Checks: Avoid passing user input directly into commands that evaluate arbitrary code, like eval() or system(). Instead, use the user input as a switch to choose from a set of developer controlled commands. • Bounds Checks: Implement proper bounds checks for non- safe languages like C++. Avoid unsafe string functions. Keep in mind that even safe languages like Python and Java use native libraries. Preventative measures
  • 39. Configuration Vulnerabilities • Applications are often installed with default settings that attackers can use to attack them. This is particularly an issue with third party software where an attacker has easy access to a copy of the same application or framework you are running. Hackers know the default account names and passwords. • For example, looking at the contents of data.py you know that there's a default administrator account named 'admin' with the password 'secret'.
  • 40. • Configuration vulnerabilities also include features that increase attack surface. A common example is a feature that is on by default but you are not using, so you didn't configure it and the default configuration is vulnerable. It also includes debug features like status pages or dumping stack traces on failures. Cont..
  • 41. AJAX vulnerabilities • Bad AJAX code allows attackers to modify parts of your application in ways that you might not expect. In traditional client development, there is a clear separation between the application and the data it displays
  • 42. • To exploit, create a user named private_snippet and create at least one snippet. • The JSON response will then be {'private_snippet' : <user's private snippet>, ..., 'private_snippet' : <attacker's snippet>} and the attacker's snippet replaces the user's. • To fix, the AJAX code needs to make sure that the data only goes where it's supposed to go. • The flaw here is that the JSON structure is not robust. A better structure would be[<private_snippet>, {<user> : <snippet>,...}]. Cont..
  • 43. Other Vulnerabilities • Buffer Overflow • Integer Overflow
  • 44. Buffer Overflow A buffer overflow vulnerability exists when an application does not properly guard its buffers and allow user data to write past the end of a buffer. • This excess data can modify other variables, including pointers and function return addresses, leading to arbitrary code execution. • Historically, buffer overflow vulnerabilities have been responsible for some of the most widespread internet attacks including SQL Slammer, Blaster and Code Red computer worms. The PS2, Xbox and Wii have all been hacked using buffer overflow exploits. Cont..
  • 45. Integer Overflow • integer overflow vulnerabilities can be just as dangerous. Any time an integer computation silently returns an incorrect result, the application will operate incorrectly. • In the best case, the application fails. In the worst case, there is a security bug. For example, if an application checks that length + 1 < limit then this will succeed if length is the largest positive integer value, which can then expose a buffer overflow vulnerability. Cont..