A .NET Developer's View Of The OWASP Top 10

Kevin Feasel (@feaselkl)

http://CSmore.info/on/owasp

Who Am I? What Am I Doing Here?

Catallaxy Services
@feaselkl
Curated SQL
We Speak Linux

OWASP

The Open Web Application Security Project is an online community founded in 2001 with the goal of improving software security.

As an organization, they release free penetation testing tools, write books on software security, and host user groups with chapters all around the world.

OWASP Top 10

One of the major contributions OWASP makes to application security is the OWASP Top 10 Application Security Risks, a periodic survey of which application security risks are most prevalent.

The latest edition is 2017, with prior editions in 2013, 2010, 2007, and 2003. The authors combine data breach analysis, practitioner surveys, and the shared expertise of leaders in the field to distill the ten largest web application security risks at the present time.

Motivation

Reviewing the top ten threats will help us get a bearing on what is happening in the industry today. Many of the top ten threats persist over time, indicating that these tend not to be ephemeral risks.

As a logistical note, covering ten threats means we will spend an average of five minutes per threat. This will limit how detailed we can get on any single threat, but I will have resources available if you wish to dig deeper into a particular topic.

Agenda

  1. Injection
  2. Authentication and Session Management
  3. Sensitive Data Exposure
  4. XML External Entities
  5. Broken Access Control
  6. Security Misconfiguration
  7. Cross-Site Scripting
  8. Deserialization
  9. Using Components With Known Vulnerabilities
  10. Insufficient Logging and Monitoring
  11. Bonus: Cross-Site Request Forgery

Injection

SQL injection is the most common injection attack, but there are others, including LDAP injection, XPATH injection, CSV injection, etc.

Injection attacks are possible whenever we are building strings which include untrusted information in one context to execute in another context. This is most common when crossing language and tier boundaries.

Injection

SQL Injection attacks are a solved problem, yet they remain at the top of the OWASP Top 10 list because SQL injection is such an easy vector of attack and typically, websites with SQL injection vulnerabilities tend to have a host of other problems, including using sysadmin for application access and providing open access to sensitive information.

In this sense, the existence of SQL injection is an organizational bellwether: if it fails this extremely simple test, it likely has failed others.

Injection

Solutions

The single best thing you can do to protect against SQL injection is to parameterize your queries. Non-terrible ORMs and stored procedures can both do this, though it is possible to misuse either. If you feel the urge to execute SQL passed in as a parameter, don't do it.

Injection

Solutions

From there, whitelists work. Use whitelists to limit the domain of valid values (easy in the case of numeric or enumeration data types). Use regular expressions if it makes sense. These whitelists should be at every level you can think of: UI, backend application, and database. This is a case where defense in depth makes good sense.

Blacklisting particular words is not a good solution because industrious people will find ways around your blacklist.

Injection

Solutions

You can also use a Web Application Firewall to intercept potentially malicious queries. These prevent many potential attacks from getting through but they are not perfect. It is possible to bypass Web Application Firewalls once you understand how they behave, but they will protect against the majority of noise.

Injection

More Details

If you want a more detailed analysis of SQL injection, I have a talk on the topic: https://CSmore.info/on/sqli. Or grab a copy of the book Tribal SQL, in which I contributed a chapter on SQL injection.

Agenda

  1. Injection
  2. Authentication and Session Management
  3. Sensitive Data Exposure
  4. XML External Entities
  5. Broken Access Control
  6. Security Misconfiguration
  7. Cross-Site Scripting
  8. Deserialization
  9. Using Components With Known Vulnerabilities
  10. Insufficient Logging and Monitoring
  11. Bonus: Cross-Site Request Forgery

Broken Authentication

Broken authentication and session management includes flaws in the frameworks we use for authentication or session management. If an attacker is able to do something like access exposed accounts or passwords or hijack a session ID, that attacker can now impersonate a valid user.

Broken Authentication

A common example of poor authentication is keeping the session ID in the query string or as part of the URL. If this is your primary authentication mechanism, it's a bad idea because someday, one of your users will tweet a link to your site.

Broken Authentication

Solutions

Store sensitive information in cookies rather than as part of the querystring or URL. It is possible to make the latter work securely but it involves a lot more work. ASP.Net defaults to use cookies only.

If you want to screw up, you can do so with this web.config setting:

<sessionState cookieless="UseURI" />

Broken Authentication

Solutions

Use tried and tested authentication methods rather than rolling your own. These are less likely to have major security vulnerabilities than code written by a team of non-specialists. In .NET, there is the ASP.Net MVC Identity system.

That said, even these can have bugs. For example: the padding oracle attack from 2010 allowed attackers to differentiate invalid cyphertext from valid cyphertext with invalid data, letting them try different things until they succeeded at combining cyphertext with data.

Broken Authentication

Other Advice

Find a good tradeoff between convenience and security with respect to timeouts. Leaving a person signed in longer is convenient, but expands the window that an attacker has to squirm into a session.

There are two timeout techniques: sliding window and fixed-length. With sliding window timeouts, you have a 30-minute (or so) window and each activity pushes the endtime back to 30 minutes. With fixed-length timeouts, you have a hard stop regardless of activity.If you want a fixed-length timeout, modify the web.config thusly:

<forms slidingExpiration="false" />

Broken Authentication

Other Advice

  • Store credentials securely. We'll cover good password security later.
  • Use robust minimum password criteria. Don't cap password lengths please!
  • Never send passwords via e-mail. In fact, you shouldn't know user passwords for your site--that's not secure.
  • Protect session IDs which are in cookies by using HTTPS to transmit cookies and protecting against cross-site scripting risks.

Agenda

  1. Injection
  2. Authentication and Session Management
  3. Sensitive Data Exposure
  4. XML External Entities
  5. Broken Access Control
  6. Security Misconfiguration
  7. Cross-Site Scripting
  8. Deserialization
  9. Using Components With Known Vulnerabilities
  10. Insufficient Logging and Monitoring
  11. Bonus: Cross-Site Request Forgery

Sensitive Data Exposure

Encrypt sensitive data that you need to access later. This includes data in databases, data in configuration files, data in backups, data in extracts, etc.

For data that you don't need to access later (like plaintext passwords to your systems), keep a hash of the data. But don't use algorithms like MD5 or SHA1; they're fine for many uses, but not for secure hashes.

Sensitive Data Exposure

What's in your S3 bucket? There are thousands of public S3 buckets with interesting information like:

  • 198 million US voter profiles
  • 14 million Verizon customer records
  • Millions of Dow Jones customer records

Rapid7 estimated in 2013 that one in six S3 buckets are available to the public. Many of those contain no sensitive information and are not risks, but some of them do have data their owners would rather not have generally available.

Sensitive Data Exposure

Solutions

Use strong adaptive algorithms for password storage. Use key derivation functions like PBKDF2 and password hashes like bcrypt, scrypt, or Argon2i. Use an arbitrarily large number of iterations with a good salt.

ASP.Net MVC 4 crypto uses PBKDF2 with 1000 iterations, but you cannot customize the number of iterations, and there is a security benefit in running some arbitrary number of times.

Zetetic has a NuGet package which uses BCrypt and 5000 iterations of PBKDF2.

Sensitive Data Exposure

Solutions

Each method has its own weaknesses:

  • PBKDF2 is weak against GPUs
  • BCrypt is weak against FPGAs (exponential CPU but not exponential memory)
  • SCrypt is strong against FPGAs (exponential CPU and exponential memory) but is newer (2009 versus 1999) and not quite as vetted
  • The Argon2 series is even newer than SCrypt (2015) but you can scale memory and CPU independently

Sensitive Data Exposure

Solutions

At its best, brute force is required to break hashing. With a good hash strategy (i.e., making hashing slow), it is not financially viable to perform a brute force attack.

The downside to slow hashing is that it's easier to perform a denial of service attack with mass login attempts.

Be sure to salt your hashes. A salt is a random set of bytes which are added to a password before it is hashed. You want a separate salt per hashed item.

Sensitive Data Exposure

Solutions

Without a good hash + salt, an attacker can use a rainbow table, which is a reverse lookup from hash to plaintext.

Sensitive Data Exposure

Solutions

When you need to encrypt data, know the difference between symmetric and asymmetric keys. Symmetric keys are good for internal data like credit card info, where the same machine encrypts and decrypts the data.

Asymmetric keys are good when you want different computers to communicate data back and forth. Asymmetric encryption is at risk from quantum computers, though symmetric encryption is still safe.

Sensitive Data Exposure

Solutions

Whichever you choose, secure the keys. Don't store them in source control or config files. Use the Data Protection API.

System.Security.Cryptography has ProtectedData.Protect and Unprotect. Valid scopes: CurrentUser and LocalMachine.

Sensitive Data Exposure

Other Solutions

  • Use a modern version of SSL/TLS to transmit sensitive information. Or, at this point, any information.
  • Discard unnecessary stored data as soon as possible and don't store what you don't need.
  • Disable autocomplete on sensitive forms and disable caching on pages with sensitive data.

Agenda

  1. Injection
  2. Authentication and Session Management
  3. Sensitive Data Exposure
  4. XML External Entities
  5. Broken Access Control
  6. Security Misconfiguration
  7. Cross-Site Scripting
  8. Deserialization
  9. Using Components With Known Vulnerabilities
  10. Insufficient Logging and Monitoring
  11. Bonus: Cross-Site Request Forgery

XXE

XML External Entity Injection (XXE) is an injection attack against XML parsers. It takes advantage of the XML spec, which allows for entities within XML. Entities are macros or placeholders that you can define in an XML file.

Those entities can also include filesystem files. XXE attacks happen when an attacker uses an XML External Entity to load data the attacker would otherwise not be able to access.

XXE

A sample of how the XML authors intended to use entities:

<!DOCTYPE doc [
<!ENTITY user "Bob">
<!ENTITY accessLevel "medium">
<!ENTITY favoriteColor "blue">
<!ENTITY greeting "Hello, &user;.  I see your access level today is &accessLevel;
  and your favorite color is &favoriteColor; - that's my favorite color too!">
]>
&greeting;

You've used entities before: &amp; for ampersand, &gt; and &lt; for comparison operators, etc. Browsers support only a built-in set of XHTML entities.

XXE

Our attack can take advantage of entities, specifically importation of external entities:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE credgatherer [ <!ELEMENT creds ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

    &xxe;
    mypass

XXE

Solutions

.NET parsers and whether they are safe:

  • LINQ to XML: safe by default
  • XmlDictionaryReader: safe by default
  • XmlDocument: safe in .NET 4.5.2 and later; unsafe before then
  • XmlNodeReader: safe by default
  • XmlReader: safe by default
  • XmlTextReader: safe in .NET 4.5.2 and later; unsafe before then
  • XmlPathNavigator: safe in .NET 4.5.2 and later; unsafe before then
  • XslCompiledTransform: safe by default

XXE

Solutions

Safety here usually means prohibiting DTDs (Document Type Definitions). As of .NET 4.0, you have three options: prohibit DTDs and throw an exception if you receive a file with a DTD; ignore the DTD but parse the file otherwise; or parse the DTD.

You should never accept untrusted XML documents with DTDs. Unless you know the origin of the XML file and can ensure that there are no external entity references, you should ignore or prohibit DTDs.

XXE

Solutions

What to do if you're not using a safe by default object:

static void LoadXML()
{
  string xml = "<?xml version=\"1.0\" ?><!DOCTYPE doc 
	[<!ENTITY win SYSTEM \"file:///C:/Users/user/Documents/testdata2.txt\">]
	>&win;";

  XmlDocument xmlDoc = new XmlDocument();
  xmlDoc.XmlResolver = null;   // Setting this to NULL disables DTDs
  xmlDoc.LoadXml(xml);
  Console.WriteLine(xmlDoc.InnerText);
  Console.ReadLine();
}
						

Recommendation: always explicitly prohibit DTDs, as that way you're sure to be safe. Don't rely on defaults.

Agenda

  1. Injection
  2. Authentication and Session Management
  3. Sensitive Data Exposure
  4. XML External Entities
  5. Broken Access Control
  6. Security Misconfiguration
  7. Cross-Site Scripting
  8. Deserialization
  9. Using Components With Known Vulnerabilities
  10. Insufficient Logging and Monitoring
  11. Bonus: Cross-Site Request Forgery

Broken Access Control

This risk is that authorized users might be able to change parameters in your application and gain access to information that they were not authorized to see.

For example, if I see http://mysite.com/customers/32144, what happens when I try to go to /customers/32145? Or /customers/32143?

Or if I try IsAdmin=1?

Broken Access Control

Broken Access Control

Solutions

With surrogate keys, use nonguessable values. Incrementing keys are great for database performance, but make it too easy for an end user to guess other people.

A solution here is indirect object references.

Broken Access Control

Solutions

Build a reference map: translate a direct reference to an indirect reference (and vice versa).

You can use System.Security.Cryptography.RNGCryptoServiceProvider to generate cryptographically random strings, and create a hashtable to support those translations back to your database keys.

Broken Access Control

Solutions

Perform access control checks. Make sure the user is authorized to see this set of data. Don't assume that having a link is the same as having authorization to that data.

Indirect object references are a supplement; access control checks are the primary winner here.

Agenda

  1. Injection
  2. Authentication and Session Management
  3. Sensitive Data Exposure
  4. XML External Entities
  5. Broken Access Control
  6. Security Misconfiguration
  7. Cross-Site Scripting
  8. Deserialization
  9. Using Components With Known Vulnerabilities
  10. Insufficient Logging and Monitoring
  11. Bonus: Cross-Site Request Forgery

Security Misconfiguration

Security misconfiguration is all about insecure configuration settings. As an example, leaving files with sensitive information accessible to the public would be misconfiguration--think password files, web.configs, etc.

You might also be displaying error messages with sensitive information: deployed code folders, internal source code, call stacks, framework/server versions, data sources and passwords, etc.

Security Misconfiguration

Good idea: using Elmah to store log data.

Bad idea: exposing Elmah data to the broader internet.

Security Misconfiguration

Solutions

Set custom errors on:

<customErrors mode="On" defaultRedirect="Error.aspx" redirectMode="ResponseRewrite" />
(or use RemoteOnly). This creates a custom page and redirectMode hides that there was ever an error and never shows the end user that there was a 500 error.

This will cause the web purists pain but prevents potential configuration exposure.

Security Misconfiguration

Solutions

Secure trace.asd. Limit what you write to trace. For example, don't write connection strings to the trace. In web.config, you can easily turn it off:

<trace enabled="false">

Security Misconfiguration

Other Solutions

  • Keep libraries & apps up to date
  • Disable or remove unnecessary ports, services, pages, accounts, privileges, etc.
  • Encrypt sensitive web.config details

In an administrative command prompt, run:

aspnet_regiis -site "sitename" -app "/" -pe "connectionStrings"

This uses the RSA key on the server to perform symmetric encryption on web.config's connection strings.

Security Misconfiguration

Other Solutions

  • Use web.config transformations to configure defensively on deployment, removing debugging and tracing logic just in case somebody accidentally includes it in the build.
  • Ensure security within the build. For example: fail the build if you have the debug flag set.
  • Go into retail mode. On the PC's machine.config:

<system.web>
<deployment retail="true" />

Agenda

  1. Injection
  2. Authentication and Session Management
  3. Sensitive Data Exposure
  4. XML External Entities
  5. Broken Access Control
  6. Security Misconfiguration
  7. Cross-Site Scripting
  8. Deserialization
  9. Using Components With Known Vulnerabilities
  10. Insufficient Logging and Monitoring
  11. Bonus: Cross-Site Request Forgery

Cross-Site Scripting

Cross-site scripting is where you get a user to execute unexpected code on a website. It is very similar to injection attacks, but focuses around JavaScript, CSS, or HTML rather than SQL, LDAP, etc.

Cross-Site Scripting

There are two major themes with XSS: reflected and persistent.

Reflected XSS is where an attacker sends a modified link, adding malicious querystring data. Typically, the attacker distributes the link via e-mail, social media, and on forums. Without the link, a potential victim would not see XSS.

Persistent XSS is where an attacker is able to save malicious code in a database and have it appear without needing a reflection link.

Cross-Site Scripting

There are several things you can do once you have exploited a Cross-Site Scripting vulnerability. You can run arbitrary scripts, access objects in the DOM, and even redirect unwary users to another site, such as a phishing site meant to harvest credentials.

Cross-Site Scripting

Solutions

Beat XSS with defense in depth. First, use an output encoding library. Microsoft has the Anti-XSS framework, which is built into .NET now: System.Web.Security.AntiXss has AntiXssEncoder.HtmlEncode() and HtmlDecode() methods, as well as encoders and decoders for CSS, JavaScript, URLs, and XML.

Cross-Site Scripting

Solutions

NuGet also has the AntiXSS library, meant for old versions of the .NET Framework prior to when they built this in. This library can encode JavaScript, XML, LDAP, CSS, etc. code. For example:

Microsoft.Security.Application.Encoder.JavaScriptEncode("some string");

Cross-Site Scripting

Solutions

If you're using ASP.NET MVC, the Razor view engine auto-encodes by default when you use @object or Html.Encode(). If you want to restore markup, use Html.Raw().

Cross-Site Scripting

Solutions

Whitelists are a viable solution, like with injection attacks. The encoding in the libraries above is a fancy form of whitelist, but you can build your own regular expressions as well to create custom whitelists.

Cross-Site Scripting

Ever get this error?

Cross-Site Scripting

Solutions

.NET automatically validates page inputs and protects you against accepting potential malicious scripts...but it can be a little too aggressive, like throwing this HttpRequestValidationException on a password column with < in it.

Cross-Site Scripting

Solutions

In general, you want these protections, so go to web.config and make sure to set:

<pages validateRequest="true">

But you might want to narrow that down a bit.

You can do this at the page level:

<@ Page ValidateRequest="false" ...

In .NET 4.5 or later, you can enable or disable request validation for individual WebForms controls, like a password box.

Cross-Site Scripting

Solutions

For ASP.Net MVC, you can decorate model attributes to ignore enoding:

[AllowHtml]
public string Password { get; set; }

Cross-Site Scripting

Solutions

You can use the X-XSS-Protection browser header to add an additional layer of protection against Cross-Site Scripting attack attempts. This works for pretty much every browser except Firefox.

Cross-Site Scripting

Solutions

You can also use Content Security Policies to protect against attacks. With a CSP, you can define valid domains and subdomains for things like:

  • JavaScript
  • Cascading Stylesheets
  • Images
  • Fonts
  • HTML5 Media (audio, video, etc.)
  • Child frames

This helps because user-defined data could be exposed from a different subdomain, one without access to execute JavaScript code or open iframes.

Agenda

  1. Injection
  2. Authentication and Session Management
  3. Sensitive Data Exposure
  4. XML External Entities
  5. Broken Access Control
  6. Security Misconfiguration
  7. Cross-Site Scripting
  8. Deserialization
  9. Using Components With Known Vulnerabilities
  10. Insufficient Logging and Monitoring
  11. Bonus: Cross-Site Request Forgery

Deserialization

Deserialization attacks really came onto the scene in 2015, when security researchers found serialization vulnerabilities in Java. We saw that attackers could perform remote code execution by sending serialized code to a number of applications, all of which use Java's "commons collections" library, a very popular library. Vulnerable applications included WebLogic, WebSphere, JBoss, Jenkins, etc.

Since then, we've learned that .NET applications are also vulnerable.

Deserialization

The most common deserialization attack is in JSON deserialization, as seen in Breeze and NancyFX. There was also an XML deserialization flaw in DotNetNuke.

Newtonsoft's JSON.Net parser is relatively safe, but Breeze uses it and ended up being vulnerable due to coding choices. Breeze configured JSON.Net to use TypeNameHandling.All and had a Tag object in its SaveOptions class:

public class SaveOptions {
 public bool AllowConcurrentSaves { get; set; }
 public Object Tag { get; set; }
}

Deserialization

If you deserialize into a FileSystemInfo object and an attacker sends a string where part of the path begins with ~ (e.g., \\SomeServer\~MyShare), then Windows automatically calls GetLongPathName() on the string. If the path is a UNC path, Windows makes an SMB request, and an attacker might be able to perform SMB credential relaying if the attacker is on your local network.

Deserialization

Solutions

Serialize data, not objects. The biggest risk with deserialization attacks is around binary serialization. If you have straight data in JSON or XML format and you prevent your deserializer from converting untrusted serialized inputs into objects, you should be safe.

When you deserialize objects, deserialize them into specific defined types, ideally classes within custom assemblies. Don't deserialize to Object, IRunnable, or other low-level classes or interfaces. You could deserialize to sealed classes so attackers cannot create derived classes from your class.

Never deserialize untrusted binary objects.

Deserialization

Other Solutions

  • Don't serialize delegates--attackers can use delegates to execute arbitrary code.
  • Don't use .NET remoting. If you need remoting, you deserve what you get with WCF. Better just not to use remoting at all.
  • If you generate the message, sign the messages as part of the serialization process and refuse to deserialize messages which are not signed.

Agenda

  1. Injection
  2. Authentication and Session Management
  3. Sensitive Data Exposure
  4. XML External Entities
  5. Broken Access Control
  6. Security Misconfiguration
  7. Cross-Site Scripting
  8. Deserialization
  9. Using Components With Known Vulnerabilities
  10. Insufficient Logging and Monitoring
  11. Bonus: Cross-Site Request Forgery

Using Broken Stuff

Things to think about:

  • Old encryption cyphers
  • Old HTTP security protocols (e.g., TLS 1.0 or 1.1)
  • Software with known backdoors or malicious components

Using Broken Stuff

Maybe you should update that out-of-date version of Struts with known vulnerabilities before somebody goes and steals credit information for basically everybody in the United States.

Maybe you should update that out-of-date version of Wordpress with known vulnerabilities before somebody finds and pops your...too late.

Using Broken Stuff

Solutions

Keep track of release notes for versions of libraries used. This can mean tracking mailing lists, GitHub pushes, NuGet package updates, and developer team blogs.

This can be a time-consuming exercise, particularly for large companies with a gigantic library surface area.

Using Broken Stuff

Other Solutions

  • Having a central NuGet repo can make it easier to keep versions of libraries in sync
  • Look at threat intelligence and exploit databases, as well as third-party tools like Metasploit
  • OWASP Dependency Check can find versions of .NET or Java packages with known vulnerabilities
  • For JavaScript, look at retire.js

Agenda

  1. Injection
  2. Authentication and Session Management
  3. Sensitive Data Exposure
  4. XML External Entities
  5. Broken Access Control
  6. Security Misconfiguration
  7. Cross-Site Scripting
  8. Deserialization
  9. Using Components With Known Vulnerabilities
  10. Insufficient Logging and Monitoring
  11. Bonus: Cross-Site Request Forgery

Logging & Monitoring

Gut check time:

  1. Do you log failed login attempts?
  2. Do you log successful login attempts?
  3. Do you log "valuable" operations?
  4. Do you ever look at those logs?
  5. Do you know what to look for in those logs?

Logging & Monitoring

.NET has a number of logging frameworks, including Elmah. You can also write out log messages to an external log collection process (Splunk, Logstash, Flume).

Logging & Monitoring

Solutions

Determine what high-value scenarios can occur in your system. For example, significant settings changes, transfers of funds, chains of failed login attempts followed by a successful attempt, and potential injection attacks (e.g., SQL injection attempt, Cross-Site Scripting attempt, deserialization attack attempt, XML External Entity attempt). Log these as well as other things which might indicate an attacker or fraudulent behavior.

Simply having the data is an important part of the process, but that's only half the battle. Then, somebody should read the log and understand what actions to take: perform an audit, blackhole an IP address, etc.

Logging & Monitoring

Solutions

Things you may want to log:

  • Input and output validation failures (e.g., invalid parameters, invalid data encodings)
  • Authentication successes and failures
  • Authorization successes and failures
  • Tampering: session cookies, querystrings
  • Application errors, especially syntax and runtime errors
  • High-risk functionality: adding/removing users, assigning important permissions, sysadmin duties, accessing sensitive data, data imports

Logging & Monitoring

Solutions

Details you should have:

  • When the event occurred
  • Which application, which server, which service, which geolocation, where in the code
  • Who performed the operation (IP address, machine identifier, user account)
  • What event occurred, including event details, severity, and description

This list is NOT comprehensive!

Logging & Monitoring

Solutions

Details you should not have:

  • Application source code
  • Session IDs, access tokens, passwords
  • Database connection strings
  • Encryption keys
  • Sensitive personal information: name, payment card data, bank account data, PHI
  • Information which is illegal to collect or where a user has opted out of collection

Include these and you might run afoul of A3. Sensitive Data Exposure.

Agenda

  1. Injection
  2. Authentication and Session Management
  3. Sensitive Data Exposure
  4. XML External Entities
  5. Broken Access Control
  6. Security Misconfiguration
  7. Cross-Site Scripting
  8. Deserialization
  9. Using Components With Known Vulnerabilities
  10. Insufficient Logging and Monitoring
  11. Bonus: Cross-Site Request Forgery

Cross-Site Request Forgery (CSRF or XSRF)

This is no longer in the OWASP Top 10, but was in RC1. The topic is interesting enough that I'd still like to cover it, although recent OWASP data indicates that it shows up in approximately 2% of websites nowadays.

CSRF

Cross-Site Request Forgery happens when you, as an attacker, create a forged HTTP request to trick a user authenticated on some other site into submitting a form on your site.

Once tricked, the attacker can perform any web operation through the victim.

The only potential differentiator between a normal request and CSRF is that the referrer is from a different domain.

CSRF

CSRF is possible because authenticated sessions are persisted via cookies (remember--we don't want that sensitive data in the querystring!). The attacker creates a legitimate request to the target, and the victim's browser issues the request as part of opening the attacker's website.

CSRF

Solutions

The best solution is to use an anti-forgery token: a random string known to the legitimate page and the browser (via a cookie) but not the attacker. A random, per-page load token prevents replay attacks from working, as the replay will use an old token rather than the current one.

CSRF

Solutions

In ASP.Net MVC:

View:

using (Html.BeginForm()) { @Html.AntiForgeryToken() }

Controller:

[ValidateAntiForgeryToken]
public ActionResult Index(...)

In ASP.Net WebForms, it's a manual process involving storing a random token to ViewState.

CSRF

Other Solutions

  • Perform referrer checking
  • Browsers have Cross-Origin Resource Sharing (CORS) defense, protecting against certain types of cross-origin attacks
  • Force reauthentication before performing important actions
  • Use the "SameSite=strict" flag on cookies to prevent cross-site misuse of cookies

Wrapping Up

This has been a quick survey of the OWASP Top 10 Application Security Risks, 2017 edition. Our examples focused on .NET but the top ten risks apply to all web platforms, although the specifics of protection mechanisms will naturally differ.

Wrapping Up

To learn more, go here: http://CSmore.info/on/owasp

And for help, contact me: feasel@catallaxyservices.com | @feaselkl