Forem: Tolga Ünlü

Defensive Coding Reloaded: A Guide To Active Web Application Defence

Tolga Ünlü — Thu, 21 Apr 2022 20:59:23 +0000

Demo
The demo application was implemented in the PHP Sandbox, you can find the application here.

Resources
Here is the list of links to further resources that I originally included in my speaker notes.

Catching Attackers with Traps

Tolga Ünlü — Thu, 09 Dec 2021 12:15:21 +0000

Sometimes, a simple trap or honeytoken placed at the right spot in your application can be enough to catch suspicious activity. This video from Shakacon by two Application Security Engineers at Netflix is an example implementing this idea with a project called Ensnare (unfortunately not maintained anymore).

I was wondering whether this form of attacker detection is actually practiced by you folks and what your experiences were in regards to successes, issues, implementation and maintenance effort.

Another, more recent illustration of this idea can be found in this talk by Dana Epp:

Cool ES6 Proxy Hacks

Tolga Ünlü — Thu, 10 Jun 2021 11:23:57 +0000

Coming across this creative approach of using fetch, I was wondering in what cool ways you folks take advantage of JavaScript ES6 Proxies?

Identifying Web Developer Awareness of Attack Attempts

Tolga Ünlü — Mon, 23 Nov 2020 11:14:23 +0000

Hello #DEVCommunity!
Get involved in making web applications self-defending and attack-aware. Our research aims to identify roadblocks in the integration of attack detection and response capabilities.

Most attacker activities involve a probing phase in which an attacker attempts to discover exploitable vulnerabilities. As many of such attack attempts could be detected while validating an application's input, the goal of our survey is to identify whether developers understand attack indicators and how they can be best supported in building detectors for such indicators.

Participation Requirements

Are you of legal age (18+) and have experience in web development or have developed applications using web technologies? Then participate in our survey and support us with your professional insights.

Survey Details

The survey is questionnaire-based and consists of three sections:

In the first section, you will be asked questions on your experience with security controls and input validation.
The second section consists of questions that will identify whether you can detect attack indicators.
In the last section, you will be asked some general questions such that we can link you and your answers to a specific developer profile.

The survey can be accessed here: https://forms.gle/NCH8hfbTggdVSmVe9

Feel free to get in touch with me should you have any questions or require further information. You can find my contact details on my personal website.

Your participation is appreciated and will support our goal of developing a pragmatic and usable attack-awareness integration solution. You are more than welcome to share this survey with your developer friends and colleagues.

Attack-Driven Defense for Web Applications

Tolga Ünlü — Tue, 07 Jul 2020 11:01:33 +0000

If you look at the common security controls that we are building into our web applications, you'll notice that they often do not have a feedback mechanism which tells the developers how the controls are performing against real threats in a production environment.

This lack of feedback is a lost opportunity to gain a better understanding on real and imminent threats, which in turn could help developers to prioritize and improve their secure development efforts:

Discovering generic attack indicators to build security controls that require less maintenance and can be used in different parts of the application.
Being able to see design flaws and rebuilding parts of an application which are secure by design.
Building detection points that look for threat indicators and make the application respond defensively when a number of those detection points are triggered.

Utilizing this feedback to drive the security efforts of your development team is known as attack-driven defense.

As this form of defense seems to be rather uncommon, I would like to hear your thoughts as developers on this, especially regarding the possibilities and shortcomings you see with this defense model.

If you are keen to learn more on how to utilize detection points to make your application attack-aware, have a look at this article where I give a brief introduction to this concept:

Detecting Attackers from Within

Tolga Ünlü ・ Jun 29 '20 ・ 6 min read

#security #webdev #javascript #tutorial

Detecting Attackers from Within

Tolga Ünlü — Mon, 29 Jun 2020 11:27:33 +0000

Modern secure development practices like “shift left” security focus on resolving security issues early and within the development process. This includes the implementation of proactive controls, such as security logging and monitoring, which can give you insights into your application’s current security posture. In addition, knowing what goes on in your application from a security perspective can be further utilized to identify attacker activity by making your application attack-aware.

Attack-aware applications, as described by the OWASP AppSensor project, rely on detection points, controls in your application code that check for blatant indicators of attacker activity. To see such detection points in action, the following parts of this article will go through some of them implemented within a small demo application. The demo application is built with the Express web application framework and uses detection points built as validators from the express-validator module.

The application itself is very limited in functionality and provides only one endpoint (/ticket) to submit user-controlled data. The submitted data is supposed to be a ticket, a JSON object consisting of three properties which will be validated by the detection points:

The demo application is available as a Glitch project (hit the Remix to Edit button to work on your own instance of the application):

Note: Use the following link if the embedded glitch project is not loading

Intrusion Detection with Detection Points

As previously mentioned, the idea of detection points is to check for blatant indicators of attacker activity, activities that you would never expect from a benign user so to speak. In the demo application for example, a benign user can select only one of three possible ticket priority values from a dropdown menu. Being able to submit any other value is a sign of request tampering by using an interception proxy like OWASP ZAP:

You can check for tampering activities with simple input validators such as those in the following code snippet:

const detectionPoints = [
  body("priority")
  .exists().withMessage("Data Missing from Request").bail()
  .isIn(["low", "medium", "high"]).withMessage("Violation of Input Data Integrity"),

  body("title")
  .exists().withMessage("Data Missing from Request"),

  body("description")
  .exists().withMessage("Data Missing from Request")
];

The validators check only for the parameters provided in the request body (body("priority"), body("title"), body("description)) as these are the only ones of interest. For all three parameters, the first validator checks if the parameter exists since it might has been removed or modified. You can then chain further validators as done with the priority parameter where the next validator in the chain checks if the submitted priority value isIn the array of acceptable values.

The detection points so far were implemented with the built-in validators, the express-validator module provides also a way to implement custom validators. This can be handy if you want to make use of existing modules such as Isomorphic DOMPurify for detection purposes:

const detectionPoints = [
  // ...
  body("description")
  .exists().withMessage("Data Missing from Request")
  .custom(value => {
    if (DOMPurify.sanitize(value) !== value) {
      throw new Error("Cross Site Scripting Attempt");
    }
    return true;
  })
];

This custom validator does a lot more complex processing than the previous ones which is abstracted away from the developer behind a single method call. It is, however, this usable abstraction that makes it convenient to utilize DOMPurify for XSS detection, an attack class which is rather ineffective to detect with the use of simple input validation controls.

This is an important aspect of implementing detection points as you will not want to spend too much time with “detection engineering”. The focus should be on implementing simple but effective detection points, be it by adding new detection points to your application or by enhancing existing input validation controls.

Intrusion Response

With the previously listed detection points in place, the demo application is now capable of detecting attacker activity. The logs generated by the triggered detection points can give the development team important insights into which part of the application is attacked and which attack techniques are deployed. To take this one step further, the triggered detection points can also be utilized to respond back defensively.

The decision whether and how to respond back can be based on a set of rules or thresholds that are exceeded. The demo application uses the latter approach to convey the idea of a defensive response:

class AttackMonitor { 
    constructor(threshold = 4){ 
        this.threshold = threshold; 
        this.detections = 0; 
    } 
    log(error,request){ 
        console.log(`[*] ${error.msg} @ [${request.method}] ${request.route.path} - request.${error.location}.${error.param}`); 
        this.detections += 1; 
    } 
    isThresholdExceeded(){ 
        return (this.detections > this.threshold); 
    } 
}

// ...

app.post("/ticket", (request, response) => {
  if(attackMonitor.isThresholdExceeded()){ 
    console.log(`[*] Detection threshold exceeded - [${request.method}] ${request.route.path} is deactivated`); 
    response.end(); 
  } 
  else { 
    // ...
  }
});

The ticket creation logic above is skipped when the number of triggered detection points exceeds a predefined threshold value. For real-world applications, however, you will want to consider more realistic responses such as:

Requiring authentication for sensitive actions
Deactivating accounts associated with attacker activity
Reporting attacker activity to your development team on Slack
Redirecting attackers to a honeypot hosting the same application but prepared with believable dummy data

These are just a few examples and your response capabilities are only limited by the technology with which your application is developed.

Conclusion

Accepting that the security measures in your application can and will be bypassed indicates a strong sense for security. It is therefore important that the security measures in place should not only focus on the preventive part but also provide the capabilities to detect and act on ongoing attacks in a timely fashion.

Attack-aware applications make the best of preventive controls by utilizing them as detection points to establish an attack-driven defense within the application.

Your Thoughts

As intrusion detection and response within the application seems to be rather uncommon, it would be interesting to hear your thoughts on this concept. What do you think about this concept in general, what limitations and possibilities do you see from a developer's perspective?

If you want to stay up-to-date on the latest developments on this topic with research papers, articles and also developer studies in which you are welcome to participate in, then feel free to follow me here on DEV or Twitter.

Further Resources

I have gathered here a few resources that you can look into if you want to learn more about attack-aware applications as well as attack-driven defense.

Reading Material

Intrusion detection: doing it wrong
The detection points effectivity relies heavily on its secrecy among others. While security-by-obscurity is not the best strategy in certain contexts, it is, however, quite effective for detection purposes as explained by Michał Zalewski.
OWASP AppSensor Guide | OWASP AppSensor
Besides more than 50 detection points described in the OWASP AppSensor guide, the guide also includes 8 illustrative case studies on integrating attack awareness into different types of applications ranging from B2B web services to smart meters. The guide also covers advanced thresholds and responses in more detail.
OWASP Top 10 Proactive Controls 2018
The proactive controls guide and especially the chapter on implementing security logging and monitoring provides more details and further references on the design and implementation of secure logging which was not covered in this article.
For Real Security, Don't Let Failure Be Your Measure of Success
Zane Lackey writes in this article on the importance of not only focusing on how to keep the bad guys out (prevention) but also to think about what to do once they are in (detection and response).

Videos

Security Vulnerabilities Decomposition: Another Way To Look At Vulnerabilities

In this presentation, Katy Anton demonstrates how to decompose vulnerabilities into security controls (including detection points) that can be used by developers.

Whatever happened to attack aware applications?

Matthew Pendlebury talks in this presentation about attack-aware applications and why they still don't seem to be commonplace.

Lessons learned defending web applications in the age of DevOps/Cloud

In this keynote talk @ DevSecCon Singapore 2018, Zane Lackey shares his practical lessons learned at Etsy on how to defend modern web applications in a DevOps world. This talk will cover different topics, including obtaining security visibility.

AppSensor: Real-Time Event Detection and Response

This talk, given by John Melton, presents the OWASP AppSensor project and the model of self-protecting applications.