DevOoops (Increase awareness around DevOps infra security) - VoxxedDays Ticin...Gianluca Varisco
Gianluca Varisco presented on security issues related to DevOps infrastructure. He discussed potential exposures in tools like GitHub, revision control systems, continuous integration tools like Jenkins, AWS configuration files, client provisioning tools, Elasticsearch, Redis, and Memcache. Some key risks included exposing private source code repositories, misconfigured systems with default credentials, and services listening on public interfaces without authentication. He emphasized the importance of access control, updating software, changing default keys, and firewall configuration.
1) The document discusses software supply chain security and examples of known attacks, including typosquatting, project takeovers, account takeovers, and inserting malware or backdoors into dependencies.
2) It provides details on specific past attacks, such as those on the event-stream, eslint, and electron-native-notify packages, how they were carried out, and their goals.
3) The presentation recommends steps developers can take to help protect their software supply chains, such as carefully managing dependencies, setting up a SECURITY.md file, enabling GitHub security features, and using two-factor authentication.
Building a Threat Model & How npm Fits Into ItAdam Baldwin
This document discusses threat modeling as it relates to npm, the package manager for JavaScript. It provides an overview of how npm threat models by considering assets, attack surfaces, and threat actors. It then outlines some key risks to npm like compromised accounts, known vulnerabilities in packages, and malware. The document concludes by covering mitigations npm has implemented, such as two-factor authentication, auditing for vulnerabilities, package signing, and automated threat detection.
DevOoops (Increase awareness around DevOps infra security) - VoxxedDays Ticin...Gianluca Varisco
Gianluca Varisco presented on security issues related to DevOps infrastructure. He discussed potential exposures in tools like GitHub, revision control systems, continuous integration tools like Jenkins, AWS configuration files, client provisioning tools, Elasticsearch, Redis, and Memcache. Some key risks included exposing private source code repositories, misconfigured systems with default credentials, and services listening on public interfaces without authentication. He emphasized the importance of access control, updating software, changing default keys, and firewall configuration.
1) The document discusses software supply chain security and examples of known attacks, including typosquatting, project takeovers, account takeovers, and inserting malware or backdoors into dependencies.
2) It provides details on specific past attacks, such as those on the event-stream, eslint, and electron-native-notify packages, how they were carried out, and their goals.
3) The presentation recommends steps developers can take to help protect their software supply chains, such as carefully managing dependencies, setting up a SECURITY.md file, enabling GitHub security features, and using two-factor authentication.
Building a Threat Model & How npm Fits Into ItAdam Baldwin
This document discusses threat modeling as it relates to npm, the package manager for JavaScript. It provides an overview of how npm threat models by considering assets, attack surfaces, and threat actors. It then outlines some key risks to npm like compromised accounts, known vulnerabilities in packages, and malware. The document concludes by covering mitigations npm has implemented, such as two-factor authentication, auditing for vulnerabilities, package signing, and automated threat detection.
Hunting for malicious modules in npm - NodeSummitAdam Baldwin
Ever since the threat of an npm worm became public we've been thinking about how to detect malicious modules in our ecosystem and how to provide security teams auditing modules with tooling and intel to make informed decisions about module risk. We've built a system to analyze modules based on their installation behavior. This talk will discuss the results of this endeavor and share the interesting findings from this new and previously unexplored dataset and try to answer the question if a npm worm is lurking in the shadows.
- Continuous Security involves keeping vulnerabilities out of production code through thorough design, code reviews, testing and automation. It also requires actively monitoring production systems and engaging in ongoing security practices like internal bug hunting and penetration testing. Shifting organizational security culture is important as well, with support from leadership and a focus on building accountability, trust and enforcement over time.
Node Security Experiments discusses security issues in the Node.js ecosystem. It covers topics like malicious modules hosted on NPM, insecure installation scripts, typosquatting vulnerabilities, password exposure, auditing packages for vulnerabilities, static analysis tools to detect security issues, and challenges of keeping up with the large number of packages. The document also mentions detecting and preventing specific security vulnerabilities, tools for auditing packages like NSP and Retire.js, potential bots in the ecosystem, and challenges with binary modules and exposing vulnerabilities in Node.js core.
The Art of Identifying Vulnerabilities - CascadiaFest 2015Adam Baldwin
The document discusses identifying vulnerabilities through understanding systems and code, thinking like an attacker, and following data flows from sources to sinks. It provides examples of testing a JavaScript milliseconds conversion utility by generating strings of increasing length to trigger a regular expression denial of service vulnerability in one of its sinks. The talk emphasizes gaining knowledge of nuances, thinking like an attacker to find unintended uses of systems, and persistent testing through curiosity to identify vulnerabilities.
Node Day - Node.js Security in the EnterpriseAdam Baldwin
This document discusses Node.js security in the enterprise. It covers communicating security priorities between technical and business teams, gathering intelligence on vulnerabilities, and implementing technical controls like linting, testing, shrinkwrapping dependencies, and retire.js to detect vulnerable modules. It emphasizes that enterprises are responsible for vetting all dependencies and that the greatest vulnerability is often developers, so peer review is important.
The document discusses the Node Security Project and responsible security disclosures. It notes that while they had control over code linting and peer review, they lacked control over third party code and the npm delivery system. It suggests improvements like private issues/pull requests could help security research. The document advocates for better security education and resources through initiatives like NodeSchool.
The document discusses security and building a security-first culture. It notes that security is difficult because software has many opinions and constraints. While no software is completely secure, individuals are responsible for security and should educate themselves on vulnerabilities, validate and sanitize inputs, use cryptography, and audit code. The document encourages teaching others about security and having conversations to improve security awareness.
This document discusses the Node Security Project, which aims to audit Node.js modules to find and help fix security issues. It was presented by Adam Baldwin who founded the project. The project will audit over 30,000 modules, fix any issues found, report them to the developers, and publish the results. Developers are encouraged to contribute by auditing modules, submitting pull requests for fixes, and otherwise helping to make the Node.js ecosystem more secure.
Writing an (in)secure webapp in 3 easy stepsAdam Baldwin
The document summarizes a presentation on writing insecure web applications. It discusses common issues like insecure navigation, cross-site scripting due to lack of output encoding, and other security problems. It provides examples of these issues like navigation to malicious sites through hashbangs and XSS via unsanitized user input. The presentation recommends approaches to address these problems like using libraries for output encoding and implementing a content security policy. It also discusses other risks like cross-site request forgery, clickjacking, insecure cookie handling and more. The presentation aims to educate developers on security issues that allow writing insecure code.
This document summarizes a presentation on Django web application security given by Adam Baldwin. The presentation covered common security failures in Django projects including cross-site scripting due to improper validation of user input in templates, file uploads that do not check extensions or store files in protected directories, direct access to objects without authorization checks, and other issues. Baldwin emphasized avoiding security problems by following best practices like input validation, using middleware to set security headers, and not allowing privileged operations with HTTP GET.
Hunting for malicious modules in npm - NodeSummitAdam Baldwin
Ever since the threat of an npm worm became public we've been thinking about how to detect malicious modules in our ecosystem and how to provide security teams auditing modules with tooling and intel to make informed decisions about module risk. We've built a system to analyze modules based on their installation behavior. This talk will discuss the results of this endeavor and share the interesting findings from this new and previously unexplored dataset and try to answer the question if a npm worm is lurking in the shadows.
- Continuous Security involves keeping vulnerabilities out of production code through thorough design, code reviews, testing and automation. It also requires actively monitoring production systems and engaging in ongoing security practices like internal bug hunting and penetration testing. Shifting organizational security culture is important as well, with support from leadership and a focus on building accountability, trust and enforcement over time.
Node Security Experiments discusses security issues in the Node.js ecosystem. It covers topics like malicious modules hosted on NPM, insecure installation scripts, typosquatting vulnerabilities, password exposure, auditing packages for vulnerabilities, static analysis tools to detect security issues, and challenges of keeping up with the large number of packages. The document also mentions detecting and preventing specific security vulnerabilities, tools for auditing packages like NSP and Retire.js, potential bots in the ecosystem, and challenges with binary modules and exposing vulnerabilities in Node.js core.
The Art of Identifying Vulnerabilities - CascadiaFest 2015Adam Baldwin
The document discusses identifying vulnerabilities through understanding systems and code, thinking like an attacker, and following data flows from sources to sinks. It provides examples of testing a JavaScript milliseconds conversion utility by generating strings of increasing length to trigger a regular expression denial of service vulnerability in one of its sinks. The talk emphasizes gaining knowledge of nuances, thinking like an attacker to find unintended uses of systems, and persistent testing through curiosity to identify vulnerabilities.
Node Day - Node.js Security in the EnterpriseAdam Baldwin
This document discusses Node.js security in the enterprise. It covers communicating security priorities between technical and business teams, gathering intelligence on vulnerabilities, and implementing technical controls like linting, testing, shrinkwrapping dependencies, and retire.js to detect vulnerable modules. It emphasizes that enterprises are responsible for vetting all dependencies and that the greatest vulnerability is often developers, so peer review is important.
The document discusses the Node Security Project and responsible security disclosures. It notes that while they had control over code linting and peer review, they lacked control over third party code and the npm delivery system. It suggests improvements like private issues/pull requests could help security research. The document advocates for better security education and resources through initiatives like NodeSchool.
The document discusses security and building a security-first culture. It notes that security is difficult because software has many opinions and constraints. While no software is completely secure, individuals are responsible for security and should educate themselves on vulnerabilities, validate and sanitize inputs, use cryptography, and audit code. The document encourages teaching others about security and having conversations to improve security awareness.
This document discusses the Node Security Project, which aims to audit Node.js modules to find and help fix security issues. It was presented by Adam Baldwin who founded the project. The project will audit over 30,000 modules, fix any issues found, report them to the developers, and publish the results. Developers are encouraged to contribute by auditing modules, submitting pull requests for fixes, and otherwise helping to make the Node.js ecosystem more secure.
Writing an (in)secure webapp in 3 easy stepsAdam Baldwin
The document summarizes a presentation on writing insecure web applications. It discusses common issues like insecure navigation, cross-site scripting due to lack of output encoding, and other security problems. It provides examples of these issues like navigation to malicious sites through hashbangs and XSS via unsanitized user input. The presentation recommends approaches to address these problems like using libraries for output encoding and implementing a content security policy. It also discusses other risks like cross-site request forgery, clickjacking, insecure cookie handling and more. The presentation aims to educate developers on security issues that allow writing insecure code.
This document summarizes a presentation on Django web application security given by Adam Baldwin. The presentation covered common security failures in Django projects including cross-site scripting due to improper validation of user input in templates, file uploads that do not check extensions or store files in protected directories, direct access to objects without authorization checks, and other issues. Baldwin emphasized avoiding security problems by following best practices like input validation, using middleware to set security headers, and not allowing privileged operations with HTTP GET.
18. 111 | Version 2.4.8
105 | Version 2.4.15
102 | Version 2.4.17
96 | Version 2.2.12
93 | Version 2.4.10
75 | Version 2.4.16
74 | Version 2.4.14
65 | Version 2.4.13
51 | Version 2.2.11
46 | Version 2.4.2