BsidesDelhi 2018: DomGoat - the DOM Security PlaygroundBSides Delhi
Presenter: Lavakumar Kuppan
Abstract: In a Mobile application pentest the tester focuses on identifying vulnerabilities on both the mobile app and the backend service the app talks to. However, in a web application pentest the client-side is usually ignored and the focus is placed entirely on security issues on the server-side. Modern browsers have several capabilities which make the JS code running in the browser almost as complex powerful as a mobile app and by extension also prone to serious security issues. Most pentesters remain unaware of these security issues and their severity. DOMGoat is an open source application that is developed primarily to help pentesters understand the various client-side security issues that can occur in the DOM. This includes everything from the several variants of DOM XSS to JavaScript cryptography to client-side data leakage and more. This talk will explain the various security issues that affect the DOM and also show how DOMGoat can be used to learn about these issues.
A Drupalcon Chicago presentation for coders/developers about web application security in the Drupal system. Covering Cross Site Scripting and Cross Site Request Forgeries.
You must have encountered the following image when using screaming frog.
Many websites do not have these parameters when crawling by screaming frog.
One of the most important issues for search engines is security.
Sergey Chernyshev presents about reducing the harm caused by these tools and best practices for consumers as well as creators of such 3rd party content.
Browser Wars 2019 - Implementing a Content Security PolicyGeorge Boobyer
A brief look at the history of the implementation of secure web headers and an overview of creating and monitoring a content security policy (CSP).
It used to be that browsers were something we fought against to get our sites viewed the way we wanted; now they are our allies.
Far from being dumb proprietary clients that just parse our HTML the way they want, they have evolved into complex software applications.
They provide powerful security controls to make decisions about what to display and debugging tools to enable us to investigate their actions.
It is increasingly common to find malicious exploits targeting web pages within the browser; running crypto-miners, stealing credentials and forging requests.
By implementing a set of headers to be delivered alongside our web pages, we can now work with browsers to protect our site visitors from malicious content
and control what is displayed and included on our pages.
In this session we will touch on what threats face our web pages out in the wild and what measures we can employ to work with browsers to protect them.
We will focus on implementing security headers and building a Content Security Policy, and will cover
- implementation of essential security headers;
- the initial investigation and building of a Content Security Policy (CSP);
- implementation and observation of the CSP in the wild;
- monitoring of the CSP once live;
- evidence of its effectiveness (threats thwarted).
Hopefully attendees will be convinced as to why security headers and CSP are invaluable and why projects should build in time and resources to implement them.
AtlasCamp 2014: Writing Connect Add-ons for ConfluenceAtlassian
This AtlasCamp, we're talking a lot about Atlassian Connect and the new Confluence REST API. This session will bring it all together with an overview on building a Connect add-on with Confluence. We will cover best practices when writing complex dynamic macros with respect to security, performance and maintainability.
Defeating Cross-Site Scripting with Content Security Policy (updated)Francois Marier
How a new HTTP response header can help increase the depth of your web application defenses.
Also includes a few slides on HTTP Strict Transport Security, a header which helps protects HTTPS sites from sslstrip attacks.
Slides for web-vulnerabilities talk I had at Evo Summer Python Lab'17 (Internship at EVO.company).
Overview of main types of vulnerabilities in the web applications as well as ways to prevent them. Damn Vulnerable Web Application (http://dvwa.co.uk/) and Damn Vulnerable Python Web Application (https://github.com/anxolerd/dvpwa) were used as demonstration software.
BsidesDelhi 2018: DomGoat - the DOM Security PlaygroundBSides Delhi
Presenter: Lavakumar Kuppan
Abstract: In a Mobile application pentest the tester focuses on identifying vulnerabilities on both the mobile app and the backend service the app talks to. However, in a web application pentest the client-side is usually ignored and the focus is placed entirely on security issues on the server-side. Modern browsers have several capabilities which make the JS code running in the browser almost as complex powerful as a mobile app and by extension also prone to serious security issues. Most pentesters remain unaware of these security issues and their severity. DOMGoat is an open source application that is developed primarily to help pentesters understand the various client-side security issues that can occur in the DOM. This includes everything from the several variants of DOM XSS to JavaScript cryptography to client-side data leakage and more. This talk will explain the various security issues that affect the DOM and also show how DOMGoat can be used to learn about these issues.
A Drupalcon Chicago presentation for coders/developers about web application security in the Drupal system. Covering Cross Site Scripting and Cross Site Request Forgeries.
You must have encountered the following image when using screaming frog.
Many websites do not have these parameters when crawling by screaming frog.
One of the most important issues for search engines is security.
Sergey Chernyshev presents about reducing the harm caused by these tools and best practices for consumers as well as creators of such 3rd party content.
Browser Wars 2019 - Implementing a Content Security PolicyGeorge Boobyer
A brief look at the history of the implementation of secure web headers and an overview of creating and monitoring a content security policy (CSP).
It used to be that browsers were something we fought against to get our sites viewed the way we wanted; now they are our allies.
Far from being dumb proprietary clients that just parse our HTML the way they want, they have evolved into complex software applications.
They provide powerful security controls to make decisions about what to display and debugging tools to enable us to investigate their actions.
It is increasingly common to find malicious exploits targeting web pages within the browser; running crypto-miners, stealing credentials and forging requests.
By implementing a set of headers to be delivered alongside our web pages, we can now work with browsers to protect our site visitors from malicious content
and control what is displayed and included on our pages.
In this session we will touch on what threats face our web pages out in the wild and what measures we can employ to work with browsers to protect them.
We will focus on implementing security headers and building a Content Security Policy, and will cover
- implementation of essential security headers;
- the initial investigation and building of a Content Security Policy (CSP);
- implementation and observation of the CSP in the wild;
- monitoring of the CSP once live;
- evidence of its effectiveness (threats thwarted).
Hopefully attendees will be convinced as to why security headers and CSP are invaluable and why projects should build in time and resources to implement them.
AtlasCamp 2014: Writing Connect Add-ons for ConfluenceAtlassian
This AtlasCamp, we're talking a lot about Atlassian Connect and the new Confluence REST API. This session will bring it all together with an overview on building a Connect add-on with Confluence. We will cover best practices when writing complex dynamic macros with respect to security, performance and maintainability.
Defeating Cross-Site Scripting with Content Security Policy (updated)Francois Marier
How a new HTTP response header can help increase the depth of your web application defenses.
Also includes a few slides on HTTP Strict Transport Security, a header which helps protects HTTPS sites from sslstrip attacks.
Slides for web-vulnerabilities talk I had at Evo Summer Python Lab'17 (Internship at EVO.company).
Overview of main types of vulnerabilities in the web applications as well as ways to prevent them. Damn Vulnerable Web Application (http://dvwa.co.uk/) and Damn Vulnerable Python Web Application (https://github.com/anxolerd/dvpwa) were used as demonstration software.
Yahoo has developed the de facto standard for building fast front-ends for websites. The bad news: you have to follow 34 rules to get there. The good news: I'll take a subset of those rules, explain them, and show how you can implement those rules in an automated fashion to minimize impact on developers and designers for your high-traffic website.
FIWARE Wednesday Webinars - How to Secure IoT DevicesFIWARE
FIWARE Wednesday Webinar - How to Secure IoT Devices (22nd April 2020)
Corresponding webinar recording: https://youtu.be/_87IZhrYo3U
Live coding session and commentary, demonstrating various techniques and methods for securing the interactions between Devices, IoT Agents and the Context Broker
Chapter: Security
Difficulty: 3
Audience: Any Technical
Presenter: Jason Fox (Senior Technical Evangelist, FIWARE Foundation)
Most of us are familiar with HTTP, but when it actually comes to creating cacheable web content, there is still a lot to be learned. In this presentation I will show you how to leverage specific mechanism to achieve a good hit rate without losing touch with some of the challenges of real-life web projects. Keywords: cache control, cache variations, conditional requests, stateful content, HTTP fragments, invalidation. The goals is to empower developers to control the behavior of reverse caching proxies like Varnish, Content Delivery Networks, or even browser cache, using the power of HTTP.
More information about this HTTP caching talk can be found on https://feryn.eu/speaking/leverage-http-to-deliver-cacheable-websites-codemotion-rome-2018/
Tips on Securing Drupal Sites - DrupalCamp Atlanta (DCA)cgmonroe
This is an updated version of this talk given at DrupalCamp Atlanta (DCA)
This presentation is an overview / case study of things learned by experiencing GDPR Security audits, DoS attacks, brute force login attacks, annoying robot crawlers, and hackers doing security probes.
The session will cover the following main topics with tips on how to protected against each of these.
An overview of security threats
Server Level Attacks
Code Level Attacks
User Access Attacks
Internal Attacks
Some suggestions on developing a security plan
People attending should come away with useful knowledge (modules, best practices, sites that help, front end tools and the like) that will help secure their sites.
Integrity protection for third-party JavaScriptFrancois Marier
Modern web applications depend on a lot of auxiliary scripts which are often hosted on third-party CDNs. Should an attacker be able to tamper with the files hosted on such a CDN, millions of sites could be compromised. Web developers need a way to guarantee the integrity of scripts hosted elsewhere.
This is the motivation behind a new addition to the web platform being introduced by the W3C: sub-resource integrity. Both Firefox and Chrome have initial implementations of this new specification and a few early adopters are currently evaluating this feature.
Similar to Securing your Movable Type installation (20)
4. Separate directories for CGI and contents
http://example.com
/cgi-bin/*.cgi /mt-static/
/*.html
Execute all files Prohibit CGI
5. Restrict accesses
Conceal CGI inside the DMZ, or restrict access by IP
addresses
/cgi-bin/*
more info on http://httpd.apache.org/docs/2.2/en/mod/mod_authz_host.html
6. Rename mt.cgi script
Prevent a bot access and a random guessing
https://example.com/cgi-bin/mt/mt.cgi
AdminScript XXXX.cgi
Specify as a configuration directive
in mt-config.cgi
7. Protect mt.cgi by the basic authentication
Allow access to mt-comments.cgi or mt-cp.cgi, but deny
access to mt.cgi
/cgi-bin/mt.cgi
9. You must use a different ID /
Password for the basic
authentication from your MT account
SSL is mandatory otherwise the
ID / Password can be captured
during the network transaction
10. Use SSL for the admin access
Encrypt the transaction between your browser and MT
SSL
SSL
11. Required configure in mt-config.cgi
Use relative path
StaticWebPath /mt-static
Not to mix http and https connections when fetching
images and CSS in the admin screen.
12. Configure URL for admin / and non admin CGI
AdminCGIPath Path for the admin CGI (SSL)
https://example.com/cgi-bin/mt/
CGIPath Path for the non-admin CGI
http://example.com/cgi-bin/mt/
But this is NOT enough to prohibit the non-SSL
access to the admin script
14. 2. Redirect http access to https
httpd.conf
<Directory "/home/example/www">
etc....
.htaccess
RewriteEngine On
RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^(cgi-bin/mt.cgi)$
https://%{SERVER_NAME}/$1 [R,L]
in one line
</Directory>
15. SSL cert is not expensive today
e.g. RapidSSL GeoTrust, Inc)
Go Daddy SSL are
$20 - 40 / a year