OWASP - User contributions [en]

Boston

2019-05-28T15:55:13Z

Jweiler: /* Boston OWASP Chapter Leaders */

{{Chapter Template|chaptername=Boston|extra=Follow @OWASPBOSTON on Twitter. The chapter leader is [mailto:boston@owasp.org Jim Weiler]. The Boston chapter is grateful for support from Constant Contact, Salesforce, Microsoft and Akamai for generously hosting space and their hospitality for various events.

__FORCETOC__

The Chapter would also like to thank our sponsors for their generous support.|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Boston|emailarchives=http://lists.owasp.org/pipermail/owasp-Boston}}

== Chapter Sponsor ==
[[File:SIlogostacked.png|Security Innovation|https://www.securityinnovation.com/]]

[[File:Veracode logo.png|Veracode|https://www.veracode.com/]]

== Boston Application Security Conference ==

[[Image:Boston-Banner-468x60.gif|link=2018_BASC_Homepage]] [[Image:twitter_32.png|link=https://twitter.com/@BASConf]] BASC 2019, the Boston Application Security Conference will take place 8:30am to 6:30pm on Saturday, October 19th at Microsoft, 5 Wayside Road, Burlington, MA. [[2018 BASC Homepage|Read more]]

== Chapter Meetings --- Our Fifteenth Year ==

We now use [http://www.meetup.com/owaspboston/ meetup] to organize meetings.

We meet whenever a speaker and a venue have available dates, 6:30 to 9 pm.

Everyone is welcome to come to any meeting, there is no signup or joining criteria, just come if it sounds interesting. You can join the OWASP Boston Google group at https://groups.google.com/a/owasp.org/forum/#!forum/boston-chapter. This list is very low volume (2 - 3 emails/month); it is used to remind people about each monthly meeting, inform about local application security events and special chapter offers.


Upcoming Meetings

'''May 22, 2019''' - Watertown [https://web.securityinnovation.com/athenahealth2019 CMD+CTRL Web App Hacking Cyber Range 6:00-9:00pm Partnered w/Security Innovation & Athenahealth]

YOU CAN ONLY REGISTER ON THE SECURITY INNOVATION REGISTRATION SITE AT [https://web.securityinnovation.com/athenahealth2019 THIS LINK]

Location: [https://goo.gl/maps/rTHhZcawAX1jYnhP7 Athena Health Watertown]

6PM *sharp*- '''Just bring your computer and evil inner-doer and you are ready to roll!'''

Want to test your skills in identifying web app vulnerabilities? Join OWASP Boston, Athena Health and Security Innovation as members compete in CMD+CTRL, a web application cyber range where players exploit their way through hundreds of vulnerabilities that lurk in business applications today. Success means learning quickly that attack and defense is all about thinking on your feet. Standard capture the flag using network and operating attack skills will not be much use here; understanding the OWASP Top 10 risks will help you find the vulnerabilities.

For each vulnerability you uncover, you are awarded points. Climb the interactive leaderboard for a chance to win prizes! CMD+CTRL is ideal for development teams to train and develop skills, but anyone involved in keeping your organization’s data secure can play - from developers and managers and even CISOs.

Just bring a laptop. Pizza and soda will be provided.

Venue/Location of the event:

Athena Health
311 Arsenal St.
Watertown, MA 02472
<gallery>
File:Athenahealth Watertown Map.jpg|Athenahealth Watertown Map
</gallery>
NOTE:
<b>Park in only P2 visitor lot or in garages P1 and P3. Parking is free.</b>

The main lobby door is at “S1” shuttle pickup icon.

Enter the lobby and sign in at the front desk to pick up credentials.

Directions to the event room will be provided at that time

=== Upcoming Training ===
TBD

=== Past Meetings ===

'''January 29th, 2019''' - Cambridge [https://web.securityinnovation.com/owaspboston2019 Partnered with Security Innovation]

Location: [https://goo.gl/maps/w11GUuJJAbo Quick Base office]

5PM- '''Just bring your computer and evil inner-doer and you are ready to roll!'''

Security Innovation is teaming up with OWASP Boston to offer attendees a fun "find the vulnerabilities" game - CMD+CTRL Cyber Range - that shows how hackers break into websites and teaches the importance of secure coding habits.

The CMD+CTRL Cyber Range we will be using is called ShadowBank, a banking website where players compete to find vulnerabilities, score points, and move up the leaderboard. Leveraging cheat sheets, attack tables, and expert led training sessions, platers take their shot at stealing money, manipulating share prices, and conducting other nefarious acts.

'''June 14th, 2017''' - Burlington [https://www.meetup.com/owaspboston/events/240033562/ Meetup]

Location: [https://maps.google.com/maps?f=q&hl=en&q=5+Wall+St.%2C+Burlington%2C+MA%2C+us SalesForce (was Demandware) 5 Wall St., Burlington, MA]

Everyone should report to Akamai 90 Broadway in the lobby and indicate about the Meetup. Someone form the staff will escort them to the 12th floor.

5:30 - 6:15 - '''Chat, Chew and Brew'''

6:15 - 6:45 '''News, Announcements'''

Chapter and OWASP events and news, audience announcements, questions, application security news(Google and Symantec certs, HTML5, Chrome features, SDLC and Microservices, others?)

7:00 pm ''' Is RASP Ready?'''

Runtime Application Self-Protection is overhyped, according to many analysts and pundits. RASP promises applications that protect themselves - which sounds impossible - how can an application possibly protect itself? An agent that sits inside the app sounds like a deployment nightmare at worst, and a drain on the app at best. What’s the reality? Where are we now and what have we learned?

We’ve seen deployment successes and failures, and we will draw from those specific experiences to describe:
Where does RASP work?
* What applications are well-suited for RASP?
* What types (organizational structure, culture, or skillset) of organizations are well-suited for RASP?

What is the reality of RASP?
* Is RASP a deployment model or a feature set?
* How mature is RASP? Is it an over-hyped immature space, enterprise-ready, or somewhere in between?
* Which RASP capabilities do organizations use? And how do they validate those capabilities in their own environments?
* Can RASP replace the WAF?

We will conclude, not with a sales pitch, but some lessons learned on: the three must have attributes for RASP, some suggestions on good candidates for RASP – both types of teams and types of applications, and finally - if, how, and when to get started.

''Speaker'': Michael Feiertag, CEO and Co-Founder, tCell
Before co-founding tCell at the end of 2014, Michael led a string of successful products – most recently as head of products at Okta, and prior to that, as technology director at Blue Coat. Prior to Blue Coat, Michael held product management, engineering, and sales positions at several start-ups. Michael holds a B.S. from The University of Chicago, and an M.S. from the University of Maryland

'''May 2, 2017''' - Burlington [https://www.meetup.com/owaspboston/events/239130768/ Meetup]

Location: [https://maps.google.com/maps?f=q&hl=en&q=5+Wall+St.%2C+Burlington%2C+MA%2C+us SalesForce (was Demandware) 5 Wall St., Burlington, MA]

Everyone should report to Akamai 90 Broadway in the lobby and indicate about the Meetup. Someone form the staff will escort them to the 12th floor.

5:30 - 6:15 - '''Chat, Chew and Brew'''

6:15 - 6:45 '''News, Announcements'''

Chapter and OWASP events and news, audience announcements, questions, application security news(Google and Symantec certs, HTML5, Chrome features, SDLC and Microservices, others?)

6:50 pm '''Random Number Generation - Lava Lamps, Clouds, New Standards and the IoT - Richard Moulds'''

The SANS Institute recently listed "Weak random number generators" as one of the 7 most dangerous security techniques to watch in 2017. But how do you really know how good your random numbers are? Virtualization and IoT make things worse and new standards are a wake-up call. Random numbers are the basis of security for all cryptography, yet they are often taken for granted. Without entropy, crypto is just math.

Learn why random numbers are so hard to generate and validate, compare different technologies in use today across virtualized environments, and discuss operational steps to take the risk out of random numbers and help secure cryptosystems even into the era of quantum computers.

''Speaker'': Richard Moulds, General Manager of Whitewood Security, has spoken at RSA 2017 and at several OWASP chapter events in New York, Chicago and Austin. Richard has over 20 years of experience in the area of cryptography and encryption.

'''November 2, 2016''' - Cambridge [https://www.meetup.com/owaspboston/events/234648485/ Meetup]

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 90 Broadway, Cambridge, MA 02142 (down the street from the usual location)

Everyone should report to Akamai 90 Broadway in the lobby and indicate about the Meetup. Someone form the staff will escort them to the 12th floor.

6:30 '''News, Announcements'''

7:00 '<nowiki/>''Advanced Persistent Legal Threats''' - '''''<nowiki/>'''William Gamble, JD, LLM, EMBA'''

Abstract: Good cyber security can protect IT infrastructure against many attacks. Because of the difficulty in monetizing cyber thefts, the direct loss of a breach can be limited. However, the legal costs, both from government agencies and plaintiffs, can be far greater. The legal landscape, both in the US and internationally is changing as fast if not faster than the technology.

Bio: I am a lawyer and a member of the Florida Bar.I used to practice tax, securities and banking law. I have written three books and spoken around the world on the economic efficiency of legal and regulatory infrastructures specifically in emerging markets like China. Over the past two years, I have immersed myself in cyber security. I now hold the CompTIA A+, Network+, and Security+. I will take the CASP next month. Besides keeping up with the regulations, I am studying incident response and auditing. I am also working toward my health care law certification. My hero is Dr. Johannes Ullrich.

'''September 28, 2016''' - Burlington - [http://www.meetup.com/owaspboston/events/233921522/ Meetup]

Location: [https://www.google.com/maps/place/5+Wall+St,+Burlington,+MA+01803/@42.4877956,-71.1904085,17z/data=!3m1!4b1!4m5!3m4!1s0x89e3758106c4cb55:0xc155e97a6d34883e!8m2!3d42.4877956!4d-71.1882198?hl=en Demandware] at 5 Wall St., Burlington, MA

6:00 '''News, Announcements'''

6:15 '''OWASP Top 10 #1 - Injection Flaws'''

Jim Weiler will discuss XML External Entity Injection flaws; how it works, how to prevent, code examples.

6:45 '<nowiki/>''From the Frontlines of RASP Adoption''' - '''''<nowiki/>'''Goran Begic, VP of Product, IMMUNIO'''

Runtime Application Self-Protection (RASP) is one of the newest technologies coined by Gartner and it is in early stages of adoption in the industry. It promises dynamic defense and automatic mitigation of vulnerabilities in web applications.

This presentation is a summary of experiences from several dozens of commercial evaluations and early adoptions in production that took place this year and provides some examples of situations and challenges that are not specific to any individual vendor. In this talk Goran will provide an overview of buying criteria and evaluation requirements across different industries and some typical pitfalls that can slow down adoption.

After the introduction and a brief reminder on the technology Goran will invite audience to participate in discussion about organizational requirements for adoption and operationalization of RASP.

Questions for discussion:

My application is under attack.
*What actions should I take?
*Who owns the response?
*Which attacks should I respond to and which ones can I ignore?
*How to get started with mitigation provided by technology?
*Does RASP fit with DevOps?
*Does RASP help with remediation?

What this presentation is not: This is not a product pitch in any way. Evaluation criteria, comparison of RASP with IAST and other security technologies, personal experiences and examples discussed in this talk are generally applicable to all RASP solutions.

Key takeaways:

At the end of the presentation you will:
*get a better understanding of requirements for evaluation of RASP and its use cases,
*if you can pull a successful evaluation alone, or if you will need participation of other groups / teams
*learn about critical criteria for success of RASP in production
*how this criteria different relative to appsec testing tools.

'''September 7, 2016''' - Cambridge - [http://www.meetup.com/owaspboston/events/229223967/ Meetup]

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 150 Broadway, Cambridge, MA 02142 (aka 8 Cambridge Center)

6:30 '''News, OWASP tools, documents review'''

7:00 '''Docker Containers and Application Security''' - '''Tsvi Korren'''

Docker containers are transforming the way applications are developed and deployed. Closely tied to DevOps and Continuous Delivery, containers introduce both risks and opportunities to security management in Web applications. This talk will introduce the basic concepts of containers, how companies use them today and how to support this technology while elevating the security posture of your application stacks.

Tsvi Korren, CISSP, has been an enterprise IT professional for 20 years with background in business process consulting in large organizations. Most recently at CA Technologies, he worked across verticals in government, retail, financial institutions and healthcare to implement compliance and security processes, from Identity and Access to Host and Server Controls. Tsvi is currently the director of technical services at Aqua, concentrating on building bridges between DevOps and Security.

'''June 8, 2016''' - Burlington - [http://www.meetup.com/owaspboston/events/230842887/ Meetup]

Location: [https://www.google.com/maps/place/5+Wall+St,+Burlington,+MA+01803/@42.4877956,-71.1904085,17z/data=!3m1!4b1!4m5!3m4!1s0x89e3758106c4cb55:0xc155e97a6d34883e!8m2!3d42.4877956!4d-71.1882198?hl=en Demandware] at 5 Wall St., Burlington, MA

6-6:30 '''News, announcements, job postings, etc. '''

6:30-7 '''Introduction to SQL Injection - Jim Weiler'''

7:00 '''Computer Science Curricula’s Failure - What Should We Do Now?''' - '''Ming Chow & Roy Wattanasin'''

We are still facing the same security vulnerabilities from over a decade ago. The problems are not going away anytime soon and a reason is because Computer Science curricula are still churning out students who are not even exposed to security. This talk will address the lack of emphasis on information security in Computer Science curricula, how CS curricula have an obligation, how to gradually fix the problem by integrating security into many Computer Science undergraduate and graduate classes, and success stories from students. This talk will also discuss what Tufts and Brandeis are currently working on to further address the security education problem by creating a joint cyber security and policy program that spans multiple departments. Additional points and feedback from the audience are encouraged to help with the issue. All are encourage to attend to submit your feedback to help!

Presenters:

Ming Chow - @0xmchow

Ming Chow is a Senior Lecturer at the Tufts University Department of Computer Science. His areas of work are in web and mobile engineering and web security. He was a web application developer for ten years at Harvard University. Ming has spoken at numerous organizations and conferences including the High Technology Crime Investigation Association - New England Chapter (HTCIA-NE), the Massachusetts Office of the Attorney General (AGO), John Hancock, OWASP, InfoSec World, DEF CON, Intel, SOURCE Conference, and BSides Boston. He was a mentor for a Proving Ground speaker at BSides Las Vegas in 2014 and 2015.

Roy Wattanasin - @wr0

Roy Wattanasin is an adjunct faculty at Brandeis University in both the Health and Medical Informatics and Information Security graduate programs. He spends most of his time leading, teaching and developing information security programs, finding vulnerabilities, performing incident response and working on many projects. Roy has spoken at many conferences including RSA, ISSA International, Source Conference, Braintank, Cyber Security World, OWASP and the Security BSides conferences. He is also a healthcare information security professional. He was a mentor for a Proving Ground speaker at BSides Las Vegas in 2015.

'''May 4, 2016''' - Cambridge - [http://www.meetup.com/owaspboston/events/229788205/ Meetup]

Location: Slightly different [http://www.akamai.com/html/about/locations.html Akamai] location: 90 Broadway, Cambridge, MA 02142 between Meadhall and the Mariott

6:30 '''News, OWASP tools, documents review'''

7:00 '''The ABCs of Source-Assisted Web Application Penetration Testing With OWASP ZAP''' - '''Dan Cornell'''

There are a number of reasons to use source code to assist in web application penetration testing such as making better use of penetration testers’ time, providing penetration testers with deeper insight into system behavior, and highlighting specific sections of so development teams can remediate vulnerabilities faster. Examples of these are provided using the open source ThreadFix plugin for the OWASP ZAP proxy and dynamic application security testing tool. These show opportunities attendees have to enhance their own penetration tests given access to source code.

This presentation covers the “ABCs” of source code assisted web application penetration testing: covering issues of attack surface enumeration, backdoor identification, and configuration issue discovery. Having access to the source lets an attacker enumerate all of the URLs and parameters an application exposes – essentially its attack surface. Knowing these allows pen testers greater application coverage during testing. In addition, access to source code can help to identify potential backdoors that have been intentionally added to the system. Comparing the results of blind spidering to a full attack surface model can identify items of interest such as hidden admin consoles or secret backdoor parameters. Finally, the presentation examines how access to source code can help identify configuration settings that may have an adverse impact on the security of the deployed application.

Dan Cornell is a globally recognized application security expert, Dan Cornell holds over 15 years of experience architecting, developing and securing web-based software systems. As the Chief Technology Officer and a Principal at Denim Group, Ltd., he leads the technology team to help Fortune 500 companies and government organizations integrate security throughout the development process. He is also the original creator of ThreadFix, Denim Group's industry leading application security program management platform. Cornell was Principal Investigator as Denim Group researched and developed the Hybrid Analysis Mapping (HAM) technology that lies at the heart of ThreadFix, through a Small Business Innovation Research (SBIR) contract with the Department of Homeland Security's Science and Technology Directorate.

More information at: http://www.denimgroup.com/about_team_dan.html

'''April 6, 2016''' - Cambridge - [http://www.meetup.com/owaspboston/events/229223967/ Meetup]

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 150 Broadway, Cambridge, MA 02142 (aka 8 Cambridge Center)

6:30 '''News, OWASP tools, documents review'''

7:00 '''Runtime Application Self-Protection (RASP) Tools''' - '''Kunal Anand'''

This talk will highlight the latest in AppSec and dive into a different kind of solution called Runtime Application Self-Protection (RASP). We'll also explore a new methodology called language theoretic security (LANGSEC) and explain how it can outperform existing approaches like pattern matching, regular expressions, etc. This talk will lay the foundation via informal and formal theory how lexers, tokenizers and parsers work. We’ll move onto constructing an open source toolchain to analyzing data and exploring interactive data visualizations. Along the way, we’ll cover performance tradeoffs and discuss the challenges of modern application security.

Kunal Anand is the co-founder and CTO of Prevoty, a runtime application security platform. Prior to that, he was the Director of Technology at the BBC Worldwide, overseeing engineering and operations across the company’s global Digital Entertainment and Gaming initiatives. Kunal also has several years of experience leading security, data and engineering at Gravity, MySpace and NASA’s JetPropulsion Laboratory. His work has been featured in Wired Magazine and Fast Company. Kunal received a B.S. from Babson College.

=== Past Training ===

'''March 16, 2016''' - Burlington - [http://www.meetup.com/owaspboston/events/229156529/ Meetup]

Location: Demandware, Burlington.

6:00 '''News, OWASP tools, documents review'''

6:30 '''Software Security by the Numbers''' - '''Chris Eng'''

Deep dive into data we’ve collected about the state of software security in 2016
* Based on scans of 200,000+ applications over an 18-month period
* How different industries and programming languages compare to one another
* Vulnerability remediation habits and patterns
* Three characteristics of a successful AppSec program

Chris Eng is vice president of research at Veracode. In this role, he leads the team responsible for integrating security expertise into all aspects of Veracode’s technology. Throughout his career, he has led projects breaking, building, and defending web applications and commercial software for some of the world’s largest companies. Chris is a frequent speaker at premier industry conferences, where he has presented on a diverse range of topics, including cryptographic attacks, agile security, mobile application security, and security metrics. He has been interviewed by Bloomberg, Fox Business, CBS, and other media outlets worldwide.

'''January 26, 2016''' - Waltham - [http://www.meetup.com/owaspboston/events/228202040/ Meetup]

Location: Constant Contact, Waltham. Trapelo Rd. exit from Rt. 128, toward Lincoln. The parking lot entrance is on the right, at the first traffic light. Drive around to the front of the office complex, facing the highway. Enter under the clock tower. Park in the front of the building and enter in the main building lobby, continue down the hallway and you will see the innovation center, enter in the large glass doors.

7:00 '''News, OWASP tools, documents review'''

7:20 '''What Security Testing Tools Miss'''

Black Duck Software presents - Static analysis, dynamic analysis, and other testing tools are all essential weapons against adversaries. But for the 80%+ of companies worldwide that use open source software in their application development these tools are ineffective in identifying and mitigating open source security risks . This presentation will cover:

The value of static and dynamic tools, and where they best fit in the Secure Development Lifecycle

Why these tools are not useful in identifying known vulnerabilities in open source components

Controls development and security professionals can deploy to select, detect, manage and monitor open source for existing and newly disclosed vulnerabilities

Food will be provided by Constant Contact.

'''November 2015''' - Cambridge - [http://www.meetup.com/owaspboston/events/226394218/ Meetup]

When: Wednesday, November 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 150 Broadway
Cambridge, MA 02142 (aka 8 Cambridge Center)

6:30 '''News, views, announcements, conversation'''

7:00 '''Interactive Discussions (Come and ask your questions!)'''

Attendee interaction is always mentioned as a high value at meetings and was great at the MetroWest meetings, so we're doing that at Akamai this month. Some discussion starters so far: SSL certificate impacts from CA/Browser alliance decisions and SHA1 weakness; mutual (client) SSL, javascript client and server side; what the heck is threat intelligence, dev ops and faster secure SDLC.

'''July 2015''' - Metrowest

When: Wednesday, July 20, 7:00 pm

Location: Constant Contact, Innovation Center, Reservoir Place, 1601 Trapelo Road, Waltham, MA 02451

7:00 '''News, views, announcements, conversation'''

7:30 '''Access in Maliceland - Risk Based Access Control''' - '''Gunnar Peterson'''

John Lambert observed attackers win because while defenders think in lists, attackers think in graphs. Access control systems divide the system a priori into secure and insecure states. But that’s only worth the paper its printed on. A Attackers see the system as it is, for attackers, the access control scheme is the beginning of the game not the end. Determined attackers seek out access control models and then find holes that they can leverage. Access control systems that purport to protect the system are built on assumptions from which reality diverges. Application security needs a new approach to access control- adding feedback loops for risk based decisions, fine-grained, dynamic access control.

Security is a business with a very long list of issues and requirements. The spreadsheets are miles long. This makes it essential to find reusable solution patterns that can address multiple problems.This presentation looks at both medium term improvements and code examples to improve access control decisions and overall security today

Gunnar Peterson ([https://twitter.com/oneraindrop @oneraindrop]) focuses on security architecture consulting and training. Experience includes Associate Editor for IEEE Security & Privacy Journal, a Microsoft MVP for App security, an IANS Research Faculty member, a Securosis Contributing Analyst, and a Visiting Scientist at Carnegie Mellon Software Engineering Institute. He maintains a popular information security blog at http://1raindrop.typepad.com.

'''July 2015''' - Cambridge

When: Wednesday, July 8, 6:30 pm ''NOTE: It's the second Wednesday this month.''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''Interactive Discussions (Come and ask your questions!)'''

'''June 2015'''

When: Wednesday, June 3, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''Put Down the Megaphone: Effective Security Advocacy Without the Shouting''' - '''Darren Meyer'''

10 years’ experience in the InfoSec community--including work with organizations in many verticals, in sizes ranging from startups to Fortune 50 enterprises, leading Application Security teams, building and delivering security instruction to developers, managers, and InfoSec professionals—has taught me the importance of crafting advocacy for different audiences. In this talk, I share my experiences in learning to be an effective advocate with three key audiences: developers, management, and non-technical staff.

Darren is an Application Security advocate and researcher, technology hobbyist, and maker. He loves to learn, teach, nerd out, and inflict terrible puns on people. His background includes logistics, software development, and an assortment of information security roles including leading AppSec programs and professional security instruction targeting developers, managers, and InfoSec professionals.

'''May 2015'''

When: Wednesday, May 6, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''How the crowd is discovering critical vulns missed by traditional methods''' - '''Leif Dreizler'''

State of the art security programs are turning to bug bounties to leverage a vast array of skill-sets and knowledge. Learn why these programs work, when to deploy them, and how you can bring these new application security testing capabilities into your own organization. The speaker will discuss real world examples from bug bounties and focus on cases where business logic flaws and high priority vulnerabilities were found ... even with existing security testing processes in place.

Attendees will learn:

Testing methods deployed by our crowd that help them find bugs the scanners miss

Examples of the high quality of bugs our crowd is finding, including P1'sTrends which vulnerability types are found most often and whyWhat is the ROI on the pay for performance modelWhere does the SDLC merge into crowdsourced testing

Leif Dreizler is a Senior Security Engineer at Bugcrowd, the innovator in crowdsourced security testing for the enterprise. Prior to joining Bugcrowd, Leif was a Senior Application Security Engineer at Redspin, performing application security assessments. During his time at Redspin he also served as the Application Team Lead, liaising with clients at the engineering and sales level. He has also made minor contributions to the Firebug project. Leif attended the University of California, Santa Barbara where he studied Computer Science. Leif recently spoke to the NYC Security Meet-up group.

'''April 2015'''

When: Wednesday, April 1, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

Jim Weiler Will show some actual examples and patterns of SQL Injection attempts

7:00 '''Are You An Imposter? Me too!''' - '''Patrick Laverty'''

Many people in the information security field feel like a fraud, or an imposter. In reality, we often know far more, and are capable of far more than we believe we do. There is so much to know and we constantly hear about the latest groundbreaking research done by others, which makes us feel less important or worthy. Let’s talk about what Imposter Syndrome is, its prevalence, and then we can start to realize just how capable we are and go forward with the confidence in the field.

'''March 2015'''

When: Wednesday, March 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''Prioritizing Web Application Vulnerabilities – A Hacker’s Perspective''' - '''Nick Silver'''

The best application risk models capture not only the technical risk factors, but also the business context in which an asset lives. Traditionally, this is done by auditing application owners on an array of questions in order to properly classify the asset and its data – but that takes time which could be better spent elsewhere. We interviewed dozens of hackers and asked them which vulnerabilities they would look for first depending on the type of attack they wanted to carry out. We’ll walk through several examples of how to use this data as a shortcut means for prioritizing risk without the need for any pesky audit questionnaires.

Nick Silver is a Senior Solutions Architect with WhiteHat Security. He is responsible for translating business requirements into technical ones and assisting businesses in implementing web security programs. Previously, Nick led a team in WhiteHat’s Threat Research Center where they were responsible for testing more than 2,000 of their customers’ websites for vulnerabilities.

'''February 2015'''

When: Wednesday, February 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News review, announcements''' - '''Jim Weiler'''

7:00 '''Incident Response and Web Application Security - Stories from the Trenches''' - '''Fred House and Joe Ceirante'''

Mandiant has conducted numerous incident response engagements throughout its history, including a record number of 200 incidents in 2014. Mandiant consultants Fred House and Joe Ceirante will discuss case studies and trends Mandiant has observed in relation to web application security.

Topics will include the types of threat actors that target web applications, the techniques they use to compromise web applications, and the activities they perform once inside the network. Techniques for detecting and mitigating web compromises will also be reviewed. All content will be derived from the real-world compromises that Mandiant has investigated.

'''January 2015'''

When: Wednesday, January 7, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News review, risk analysis of Poodle''' - '''Jim Weiler'''

7:00 '''How a Hacker Views Your Web Site''' - '''Patrick Laverty'''

''The most popular presentation of BASC 2014''

As defenders, we have to be right 100% of the time where an attacker only needs to be right once. The attack surface of a modern web site is incredibly large and we need to be aware of all of it. Additionally, individual attacks may not always be effective but sometimes using them together can gain the desired effect. In this talk, we’ll take a look at the whole attack surface for a typical web site and the various ways that an attacker will use to compromise a site.

'''December 2014'''

When: Wednesday, December 3, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News and Views You Can Use and Abuse''' - '''Jim Weiler'''

* Some thoughts and analysis on some current app security news and other stuff
* Adobe password breach
* Reducing Web Application Firewall SQL injection false positives

7:15 '''Swift and Security''' - '''Ming Chow'''

Apple is pushing its new programming language Swift for iOS development and for many good reasons. This talk will discuss what the language has right in terms of security, the old and new security pitfalls, and what developers need to be aware of moving forward with using the new language. The fact to the matter is, iOS isn't going away, iOS developers will need to learn and use Swift, and there will be a big rush of Swift-based apps: we might as well learn how to do it right the first time around.

Ming Chow is an Instructor at the Department of Computer Science, Tufts University. Ten years of web development experience.
Specialties: Web and Mobile Development, Web and Mobile Security

'''July 2014'''

Topics: '''Grails Security''' and '''Validating Cross-Site Scripting Vulns with xssValidator'''

Presenters: '''Cyrus Malekpour''' and '''John Poulin'''

When: Tuesday, July 8, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic 1: ''Grails Security''

Grails is a framework developed for Groovy in the vein of Rails for Ruby. It provides a lot of features for web app security, but does it do enough? What might you need to implement yourself, and what might be provided? This presentation will discuss tips on securing Grails applications, including tools that the framework provides by default for security. It'll also discuss several shortcomings in the current toolset, and how you can avoid them.

Cyrus Malekpour (@cmalekpour) is currently interning at nVisium, working on web app development and security. He's currently an undergraduate student at the University of Virginia, where he's studying computer science with an emphasis on security and backend development.

Topic 2: ''Validating Cross-Site Scripting Vulns with xssValidator''

xssValidator is a tool developed to automate the testing and validation of Cross-Site Scripting (xss) vulnerabilities within web applications. Automated scanners tend to report large amounts of false-positives, and as consultants we're forced spending our time trying to verify these findings. xssValidator leverages scriptable web-browsers such as PhantomJS and Slimer.js to automatically validate these findings.

John Poulin is an application security consultant for nVisium who specializes in web application security. He worked previously as a web developer and software engineer that focused on building multi-tier web applications. When he's not hacking on web apps, John spends his time building tools to help him hack on web apps! You can find him on twitter: @forced_request and on myspace: REDACTED.

'''June 2014'''

Topic: '''Training: SQL Injection and the OWASP Zed Attack Proxy (ZAP)'''

Presenters: '''Rob Cheyne and Jim Weiler'''

When: Wednesday, June 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 - general networking, news discussion, announcements.

7:00 - main presentations

The June 4th meeting will be the second in our series of 2014 training meetings. Rob Cheyne will continue explaining and exploring SQL Injection by conducting an actual injection attack.

This will be a demo-based discussion to get into the mindset of an attacker, and show how an attacker goes after a site. Demo will include:

* BurpProxy demo
* Common authentication flaws
* SQL Injection Demo that shows the process and how it builds to a full compromise

'''Rob Cheyne''' is currently CEO of Big Brain Security. In addition to security consulting for Fortune 500 customers, he was the author of LC4, a version of the award-winning L0phtCrack password auditing tool, and he also worked on the code scanning technology that was eventually spun off as Veracode. Rob was at @stake from the very first customer all the way through to the $50M acquisition by Symantec.

'''Jim Weiler''' will introduce the OWASP Zed Attack Proxy (ZAP). This is a very powerful free OWASP intercepting proxy that lets you see, analyze, change, replay etc. every browser request and response, analyze your session, scan and attack web sites, save the results and run reports. We can't cover all the functionality but we'll show some practical tips and techniques.

Pizza, salad and soda courtesy of Akamai

'''March 2014'''

Topic: '''Training: SQL Injection, WebGoat, Cross Site Request Forgery'''
Presenter: '''Benjamin Lerner'''
When: Wednesday, March 5, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

There will be three training sessions:

One will be on SQL Injection - intro, detection, prevention, scanning and false positives. This is the most serious web application vulnerability.

The second will be on OWASP WebGoat. WebGoat is a deliberately insecure web application maintained by OWASP designed to teach web application security lessons. You can install and practice with WebGoat in either J2EE or in ASP.NET. In each lesson, users must demonstrate their understanding of a security issue by exploiting a real vulnerability in the WebGoat applications. There are hints and 39 different lesson plans on various vulnerabilities and technologies. We won't cover all of them of course!

The third will be on Cross Site Request Forgery - not a hack really, it's just the way the web works. But it causes apps to do legitimate things that you didn't ask them to do.

Pizza and drinks provided by Akamai.

'''January 2014'''

When: Wednesday, January 8, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic: '''JavaScript Verification: From Browsers to Pages'''

Modern web browsers implement a "private browsing" mode that is intended to leave behind no traces of a user's browsing activity on their computer. This feature is in direct tension with support for *extensions*, which let users add third-party functionality into their browser. I will discuss the scope of this problem, present our approach to verifying extensions' compliance with private browsing mode, and sketch our findings on several real, third-party extensions. I will then briefly describe the toolkit underlying our approach, and end with a sketch of a newer project, adapting this approach to the very different-seeming problem of statically catching errors when using the jQuery library.

Presenter: '''Benjamin Lerner'''

Benjamin Lerner has just completed a post-doctoral research position in the PLT group at Brown University, and is now a lecturer at Northeastern University. His research examines the challenges of analyzing client-side web programming, from the behavior of web pages down through the semantics of the browser. He received a PhD in Computer Science from the University of Washington in 2011, building a platform to analyze conflicts between browser extensions, and a B.S. in Computer Science and Mathematics from Yale University.

'''November 2013'''

When: Wednesday, November 6, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic: '''Attacking iOS Applications'''

Slides: [http://www.slideshare.net/kfosaaen/i-os-gcandpb On slideshare]

This presentation will cover the basics of attacking iOS applications (and their back ends) using a web proxy to intercept, modify, and repeat HTTP/HTTPS requests. (The proxy used during research was Burp; however, any HTTP intercepting proxy such as OWASP ZAP could be used) From setting up the proxy to pulling data from the backend systems, this talk will be a great primer for anyone interested in testing iOS applications at the HTTP protocol level. There will be a short (2 minute) primer on setting up the intercepting proxy, followed by three practical examples showing how to intercept data headed to the phone, how to modify data heading to the application server, and how to pull extra data from application servers to further an attack. All of these examples will focus on native iOS apps (Game Center and Passbook) and/or functionality (Passbook Passes).

Presenter: '''Karl Fosaaen'''

Karl is a senior security consultant at NetSPI. This role has allowed Karl to work in a variety of industries, including financial services, health care, and hardware manufacturing. Karl specializes in network and web application penetration testing. In his spare time, Karl helps out as an OPER at THOTCON and a swag goon at DEF CON.

'''October 2013'''

When: Wednesday, October 2, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic: '''Abusing NoSQL Databases'''

The days of selecting from a few SQL database options for an application are over. There is now a plethora of NoSQL database options to choose from: some are better than others for certain jobs. There are good reasons why developers are choosing them over traditional SQL databases including performance, scalabiltiy, and ease-of-use. Unfortunately like for many hot techologies, security is largely an afterthought in NoSQL databases. This short but concise presentation will illustrate how poor the quality of security in many NoSQL database systems is. This presentation will not be confined to one particular NoSQL database system. Two sets of security issues will be discussed: those that affect all NoSQL database systems such as defaults, authentication, encryption; and those that affect specific NoSQL database systems such as MongoDB and CouchDB. The ideas that we now have a complicated heterogeneous problem and that defense-in-depth is even more necessary will be stressed. There is a common misconception that SQL injection attacks are eliminated by using a NoSQL database system. While specifically SQL injection is largely eliminated, injection attack vectors have increased thanks to JavaScript and the flexibility of NoSQL databases. This presentation will present and demo new classes of injection attacks. Attendees should be familiar with JavaScript and JSON.

Presenter: '''Ming Chow'''

Ming Chow (@tufts_cs_mchow) is a Lecturer at the Tufts University Department of Computer Science. His areas of work are in web and mobile engineering and web security. He teaches courses largely in the undergraduate curriculum including the second course in the major sequence, Web Programming, Music Apps on the iPad, and Introduction to Computer Security. He was also a web application developer for ten years at Harvard University. Ming has spoken at numerous organizations and conferences including the High Technology Crime Investigation Association - New England Chapter (HTCIA-NE), the Massachusetts Office of the Attorney General (AGO), John Hancock, OWASP, InfoSec World (2011 and 2012), DEF CON 19 (2011), the Design Automation Conference (2011), Intel, and the SOURCE Conference (Boston 2013). Ming's projects in information security include building numerous CTF challenges, Internet investigations, HTML5 and JavaScript security, and Android forensics.

'''September 2013 - Joint Meeting with [http://www.meetup.com/Boston-cloud-services/ Boston Cloud Services]'''

When: Tuesday, September 10, 6 pm

Location: Microsoft NERD Center ''(not our usual location)''

'''Note: This is a joint meeting. Please register at [http://www.meetup.com/Boston-cloud-services/ the Boston Cloud Services meetup page] if you plan to attend.'''

There will be two presentations at this meeting:

Topic: '''People Centric Security (PCS)'''

Presenter: '''Nick Stamos'''

People Centric Security (PCS) is a new security model, presented as part of Gartner's Maverick Research 2 year ago. PCS is well suited for Cloud Business/Consumer services such as Dropbox, Google Drive, SkyDrive, etc. PCS enables users to have what they desire, and provides enterprises what they require for data governance and compliance. Nick Stamos co-founded his fourth company, nCrypted Cloud in July of 2012. His past startups include Verdasys, Phase Forward (IPO FY2004, $685M Oracle Acquisition 2010), and Amulet. He studied at Tufts University where he received a BSEE and MSEE.

Topic: '''SSL Certs'''

Presenter: '''Jim Weiler'''

Practical experiences with issuing and risk assessing SSL certs for enterprise applications on a cloud provider: who creates the CSR, how do you protect the private key on the cloud server, certs on cloud provider managed load balancers vrs 3rd party managed app servers, roles and responsibilities of cloud IT, 3rd party developer IT, enterprise IT and service providers. Jim Weiler is Application Security Architect at Starwoods Hotels and the Chapter Leader of OWASP Boston.

'''July 2013 - Doubleheader!'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, July 10, 6:30 pm

Topic: '''RailsGoat'''

Presented by: '''Ken Johnson'''

Abstract: While working to secure rails applications in a truly Agile development environment, it became clear that the Rails and Ruby ecosystem needed attention from the security community in the form of free and open training, and the events that have transpired within the last few months have only reinforced that belief. [http://railsgoat.cktricky.com/ RailsGoat] is an attempt to bring attention to both the problems that most frequently occur in Rails as well as the solutions for remediation. To accomplish this, we've built a vulnerable Rails application that aligns with the OWASP Top 10 and can be used as a training tool for Rails-based development shops.

Topic: '''PhoneGap on Android'''

Presented by: '''Jack Mannino'''

Abstract: PhoneGap is a widely used framework that allows developers to rapidly build cross-platform mobile applications using HTML5, JavaScript, and CSS. Using PhoneGap plugins, developers can call native platform APIs from browser-like applications using JavaScript. This approach introduces vulnerabilities that are not typically as prevalent within native Android applications, warranting a fresh look at the way we view mobile applications. In this presentation, we will take a deep look at the Android implementation of the framework and we will examine the overall attack surface for applications. Real-world examples of vulnerable applications will be demonstrated as well in order to provide context, entertainment, and enjoyment.

About the Speakers:

Ken Johnson is the former Manager of LivingSocial.com's application security team where he built their security program before leaving for his true home as the CTO of nVisium Security, a VA-based application security company. Ken is the primary developer of the Web Exploitation Framework and contributes to other open source application security projects as often as time permits. He has spoken at AppSec DC 2010 and 2012, OWASP NoVA and Phoenix chapters, Northern Virginia Hackers Association (NoVAH) and is a contributor to the Attack Research team.

Jack Mannino is the CEO of nVisium Security, a VA-based application security company. At nVisium, he helps to ensure that large corporations, government agencies, and software startups have the tools they need to build and maintain successful security initiatives. He is an active Android security researcher/tinkerer, and has a keen interest in identifying security issues and trends on a large scale. Jack is a leader and founder of the OWASP Mobile Security Project. He is the lead developer for the OWASP GoatDroid project, and is the chairman of the OWASP Northern Virginia chapter.

'''June 2013'''

Topic: '''We see the future…and it isn’t pretty'''

Presented by: '''Andrea Mulligan, Sr. Director at Veracode'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, June 5, 6:30 pm

In this session Andrea presents research findings from the State of Software Security Report, which offers a before the breach look at security by examining the flaws commonly found in applications of all kinds. She will also examine what the research findings mean for security, predict how these flaws could cause history to repeat itself, and discuss how security pros can help change the future.

'''May 2013'''

Topic: '''Systems Thinking + Web Security'''

Presented by: '''Akamai'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, May 1, 6:30 pm

Akamai will present on ‘Systems Thinking + Web Security’. There will also be an audience review exercise facilitated by the Akamai presenters. This is a great chance to hear some interesting perspectives on web security from Akamai, who handles about one third of all internet traffic.

'''April 2013'''

Topic: '''Go Fast. Be Secure: Effectively Govern the Use of Open Source Components Throughout the SDLC'''

Presented by: '''Sonotype'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, April 3, 6:30 pm

* Open Source Software (OSS) Component supply chain complexities and realities. Open source is constantly changing and knowing the version in your software, as well as the current version history of the component (how do you show an auditor you are using a current version) is important.
* Open Source Consumption Patterns from the Central Repository. Which versions are the most popular can tell you which versions are the most stable, useful, secure etc.
* OWASP Top 10 (A9) - Using Components with Known Vulnerabilities. To decide on the risk of OSS components with vulnerabilities, you need to know the vulnerabilities, their severity and which components they occur in as well as where in the code dependency tree they are.
* OSS Security, Quality and License policies must be woven into the development process. Knowing the number and type of open source licenses in your software can be important to the legal standing of your code and if it conflicts with any corporate standards. The licensing is also important in order to know the restrictions on changing the software.
* OSS Component Policy Examples
* Example Application Compositions Reports
* Example Use cases IDE, CI, repository, production applications
* Discussion

About Sonatype:

Sonatype operates the Central Repository, the industry's primary source for open-source components, housing more than 400,000 components and serving more than five billion requests per year from more than 60,000 organizations. The company has been a pioneer in component-based software development since its founding by Jason van Zyl, the creator of the Apache Maven build management system and the Central Repository.

'''March 2013'''

Topic: '''What is BSIMM?'''

Speaker: '''Nabil Hannan'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Nabil is Director of Vulnerability Assessments and Managing Consultant at Cigital.

The purpose of the BSIMM is to quantify the activities carried out by real software security initiatives. BSIMM is a study of the secure development practices of over 50 organizations, analyzed along the dimensions that were found in the data, not along preconceived ideas of what secure development should be.

BSIMM describes the work of 974 software security group members working with a satellite of 2039 people to secure the software developed by 218,286 developers.

The BSIMM describes 111 activities that any organization can put into practice. The activities are described in twelve practices grouped into four domains. Associated with each activity is an objective.

'''February 2013'''

Topic: '''BroBot'''

Speaker: '''Eric Kobrin, Akamai'''

When: Wednesday, February 6, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Eric Kobrin is a Senior Security Architect in the Infosec organization of Akamai Technologies, the global leader in Cloud-based application acceleration and content delivery. Eric has been involved in Software Architecture for over 15 years, having worked at such companies and IBM, Velocitude and eDiets.com. He has a passion for programming languages, security, and software performance and has worked in all layers of the software stack from hypervisors to complex servers and web applications. Eric's works have been published, presented at international conferences and patented.

His presentation will provide an analysis of the BroBot DDOS attacks, including discussion of:

* Vulnerable system discovery
* Zombie compromise
* Control structure
* Attack traffic
* Mitigation steps

'''January 2013'''

Topic: '''Third-Party Application Analysis: Best Practices and Lessons Learned'''

Speaker: '''Chad Holmes, Veracode'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Chad Holmes will present details of the work Veracode has been doing with their 3rd Party program, discuss the technical and business challenges that have arisen during that time and lead a discussion on what team members can do to help drive adoption of security best practices across their vendor community.

The flow of the presentation is designed to drive discussion within an audience – both from a technical and business perspective with some anecdotal stories. Chad wants this to be an interactive discussion so he’ll have questions and you should bring yours I’ve already sent him some. The order of the presentation is:

· Adoption rates of externally developed software

· The risk within those apps

· Some deeper stats on what “3rd party” really means (total outsourcing/total COTS produced/open source/imported libraries/etc)

· Some raw data about our experiences (to show this is based on a large sample size rather than “Look how awesome Veracode is!”)

· Challenges that will be faced (business, intellectual property, policy, analysis capabilities, etc)

· Best Practices for high rates of adoption

· Lessons Learned and Recommendations

Chad Holmes has over 10 years of software development and application security experience. During his time at Veracode, Chad has lead the redesign and execution of the third-party analysis process to allow for a more streamlined approach while still addressing common ISV intellectual property concerns. In addition to his third-party analysis responsibilities, Chad's previous work as a Security Program Manager has lead to the successful roll out and improvement of multiple corporate application security groups.

'''June 2012'''
Location - Microsoft Waltham (201 Jones Rd., Sixth Floor Waltham, MA)

Speaker '''Will Vandevanter - Rapid 7'''

'''Fingerprinting web applications of all kinds'''

This turbo talk will introduce a new Metasploit module that fingerprints "known" web applications, attempts the default credentials for the application, and runs an associated exploit or authenticated access module if applicable. Some example fingerprints in the database target common enterprise web applications including Microsoft products (Outlook Web Access, Sharepoint), printers (Xerox Document Centre), security cameras, routers, and others.

Will Vandevanter is a senior penetration tester and researcher at Rapid7. His focus interests include web application security and secure code. He has previously spoken at Defcon, SOURCE, BSides LV, and other conferences.

'''May 31 2012'''

Location - Jobspring, Boston. 545 Boylston st.

Speaker - '''Glenn Gramling, Vice President, Cenzic'''

“Cloudy with a Chance of Hack”

Cloud computing is a cost effective and efficient way for enterprises to automate their processes. However organizations need to be aware of the pitfalls of the many cloud solutions out there - one of the main being security. Most cloud applications were built for ease of use and without security necessarily in mind. Companies need to be asking their solution providers about the security measures used in developing the application and get an independent verification to make sure there are no gaping holes. With over 75% of attacks occurring through the Web, any attack through these applications can lead to leakage of confidential information and embarrassment. In this session, we'll give attendees tips and tricks to prepare them for the potential of "stormy weather."

Glenn Gramling is responsible for global sales and business development for Cenzic’s application security.

'''April 11, 2012'''

Location - Microsoft Waltham (201 Jones Rd., Sixth Floor Waltham, MA)

Speaker - '''David Eoff, Senior Product Marketing Manager, HP Enterprise Security'''

David is a Senior Product Marketing Manager, within the Enterprise Security Products division of HP focused on Fortify application security. His 18+ years of background in software and hardware enterprise marketing provides a solid foundation for his marketing of the HP security solutions.

Prior to joining Fortify in 2009 and being acquired by HP, David ran Firewall and IPS marketing for the Security division of Nokia Corporation. In addition, he has held multiple positions in product marketing, product management, channel marketing and sales while working for Oracle, EMC, Legato, BMC Software and several start-ups.

Topic - '''Gray, the New Black: Gray-Box Vulnerability Testing'''

Over the years, two key techniques have emerged as the most effective for finding security vulnerabilities in software: Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST). While DAST and SAST each possess unique strengths, the “Holy Grail” of security testing is thought to be “hybrid” – a technique that combines and correlates the results from both testing methods, maximizing the advantages of each. Until recently, however, a critical element has been missing from first generation hybrid solutions: information about the inner workings and behavior of applications undergoing DAST and SAST analysis.

This presentation will introduce you to the next generation of hybrid security analysis – what it is, how it works, and the benefits it offers. It will also address (and dispel) the claims against hybrid, and leave you with a clear understanding of how the new generation of hybrid will enable organizations to resolve their most critical software security issues faster and more cost-effectively than any other available analysis technology.

'''March 8, 2012, with the Boston Security Meetup group'''

Location - [http://maps.google.com/maps?q=Jobspring+Partners,+Boylston+Street,+Boston,+MA&hl=en&sll=42.362243,-71.081628&sspn=0.019549,0.037594&oq=jobspring&t=v&hq=Jobspring+Partners,&hnear=Boylston+St,+Boston,+Massachusetts&z=17 JobSpring, Boylston St.]

Topic - '''Corporate Espionage for Dummies: The Hidden Threat of Embedded Web Servers'''

Speaker - VP for Security Research at ZScaler, along with other speakers at the security meetup.

Today, everything from kitchen appliances to television sets come with an IP address. Network connectivity for various hardware devices opens up exciting opportunities. Forgot to lower the thermostat before leaving the house? Simply access it online. Need to record a show? Start the DVR with a mobile app. While embedded web servers are now as common as digital displays in hardware devices, sadly, security is not. What if that same convenience exposed photocopied documents online or allowed outsiders to record your telephone conversations? A frightening thought indeed.

Software vendors have been forced to climb the security learning curve. As independent researchers uncovered embarrassing vulnerabilities, vendors had little choice but to plug the holes and revamp development lifecycles to bake security into products. Vendors of embedded web servers have faced minimal scrutiny and as such are at least a decade behind when it comes to security practices. Today, network connected devices are regularly deployed with virtually no security whatsoever.

The risk of insecure embedded web servers has been amplified by insecure networking practices. Every home and small business now runs a wireless network, but it was likely set up by someone with virtually no networking expertise. As such, many devices designed only for LAN access are now unintentionally Internet facing and wide open to attack from anyone, regardless of their location.

Leveraging the power of cloud based services, Zscaler spent several months scanning large portions of the Internet to understand the scope of this threat. Our findings will make any business owner think twice before purchasing a 'wifi enabled' device. We'll share the results of our findings, reveal specific vulnerabilities in a multitude of appliances and discuss how embedded web servers will represent a target rich environment for years to come.

'''December 13, 2011, 6:30, Microsoft NERD, Cambridge, Horace Mann Room'''

'''Jeremiah Grossman – Founder and CTO WhiteHat Security'''

Directions: http://microsoftcambridge.com/About/Directions/tabid/89/Default.aspx

'''September 14 2011'''

'''Dinis Cruz - OWASP O2 Platform'''

The O2 Platform is focused on automating application security knowledge and workflows. It is a library of scriptable objects specifically designed for developers and security consultants to be able to perform quick, effective and thorough source code-driven application security reviews (blackbox + whitebox).

'''September 7 2011'''

'''Adriel Desautels – Differences between Penetration Testing and Vulnerability Scanning'''

'''July 2011'''

'''Anurag Agarwal, the founder of MyAppSecurity'''

'''Session 1 - Managing Risk with Threat Modeling'''
Threat Modeling can help by guiding the Application Development Teams to ensure your Security Policies get properly coded into the Applications at time of Development. By creating pre-approved methods of coding for your development teams, and applying them in a repeatable and scalable process, you can assist your development teams in building a secure application easily and effortlessly.

'''Session 2 - False Positive, False Negative and False Sense of Security'''
This interactive session will talk about the pros and cons of using black box testing tools and discuss their effectiveness in building a mature software security program.

'''Thursday June 2'''

Location - '''Microsoft NERD''' - http://microsoftcambridge.com/About/Directions/tabid/89/Default.aspx

'''Topic - Bringing Sexy Back: Defensive Measures That Actually Work'''

Presenter - Paul Asadoorian, Founder & CEO, PaulDotCom Enterprises

There is a plethora of information available on how to break into systems, steal information, and compromise users. As a penetration tester, I have performed testing on a regular basis that reveals severe security weaknesses in several organizations, and many of my peers have reported on the same. However, once you "own" the network and report on how you accomplished your goals, now what? Sure, we make defensive recommendations, but consistently it has been proven that security can be bypassed. Not enough focus is given to what works defensively. We have a lot of technology at our disposal: firewalls, intrusion detection, log correlation, but it provides little protection from today's threats and is often not implemented effectively. This talk will focus on taking an offensive look at defense. Applying techniques that are simple, yet break the mold of traditional defensive measures. We will explore setting up "traps" for attackers, slowing them down with simple scripts, using honeypots, planting bugs, and most importantly tying these methods to "enterprise security". This talk will also include real-world examples of the techniques in action from a live, heavily attacked site. Topics will include:

*Using wireless “attacks” on the attackers
*Implementing the Metasploit Decloak engine to find the attackers
*Setting traps to detect web application attacks
*Integrating results into your enterprise log management tool

The goal of this talk is to make defense “sexy”…

'''Presenter Bio'''

Paul Asadoorian is currently the "Product Evangelist" for Tenable Network Security, where he showcases vulnerability scanning and management through blogs, podcasts and videos. Paul is also the founder of PaulDotCom, an organization centered around the award winning "PaulDotCom Security Weekly" podcast that brings listeners the latest in security news, vulnerabilities, research and interviews with the security industry's finest. Paul has a background in penetration testing, intrusion detection, and is the co-author of "WRT54G Ultimate Hacking", a book dedicated to hacking Linksys routers.

'''Thursday May 26'''

Location - Microsoft Waltham (201 Jones Rd., Sixth Floor Waltham, MA)

'''Topic - OWASP Top 10 issue #4 – Insecure Direct Object Reference'''

Presenter - Jim Weiler, Sr. Mgr. Information Security, Starwood Hotels and President of OWASP Boston

Jim Weiler will discuss threat models, risks and various remediations of issue #4 in the 2010 OWASP Top 10 – Insecure Direct Object References.

'''Topic - A Web-Application Architecture for Regulatory Compliant Cloud Computing'''

Presenter - Arshad Noor, StrongAuth

The emergence of cloud-computing as an alternative deployment strategy for IT systems presents many opportunities, yet challenges traditional notions of data-security. The fact that data-security regulations are developing teeth, leaves information technology professionals perplexed on how to take advantage of cloud-computing while proving compliance to regulations for protecting sensitive information.

This presentation presents an architecture for building the next generation of web-applications. This architecture allows you to leverage emerging technologies such as cloud-computing, cloud-storage and enterprise key-management (EKM) to derive benefits such as lower costs, faster time-to-market and immense scalability with smaller investments - while proving compliance to PCI-DSS, HIPAA/HITECH and similar data-security regulations.

'''Presenter Bio'''

Arshad Noor is the CTO of StrongAuth, Inc, a Silicon Vally-based company that specializes in enterprise key management. He is the designer and lead-developer of StrongKey, the industry's first open-source Symmetric Key Management System, and the KeyAppliance - the industry's first appliance combining encryption, tokenization, key-management and a cryptographic hardware module at an unprecedented value. He has written many papers and spoken at many forums on the subject of encryption and key-management over the years.

''' CANCELLED '''

'''Topic – Secure Application design and Coding''' -- CANCELLED

Presenter - Josh Abraham, Rapid 7

'''Speaker Bio '''

'''April 2011'''

Ed Adams Security Innovation -- the new OWASP Exams Project and the work being done by the OWASP Academies Working Group

<br>

'''March 2011'''

Josh Abraham, Rapid 7

Owning the world, one mobile app at a time, and web services pen testing.

<br>

'''Febrary 2011'''

Rob Cheyne, CEO of Safelight Security -

Security Leadership series: Delivering a successful security presentation

<br>

'''December 2010'''

Application Architecture Security Assessment - Second session

Rob Cheyne, CEO SafeLight Security Advisors

<br>

'''November 2010'''

Open SAMM – Software Assurance Maturity Model

Shakeel Tufail is the Federal Practice Manager at Fortify, an HP company.

<br>

'''October 2010'''

Rob Cheyne, CEO SafeLight Security Advisors Overview: In this highly interactive two-part workshop, Rob Cheyne of Safelight Security will show you the basics of conducting a real-world architecture & design review. This workshop draws from Safelight's Security Architecture Fundamentals training course, a two-day course frequently used to teach Fortune 500 companies how to look at their system architectures from both the hacker's and the designer’s point of view.

'''July 2010'''

Lightning Talk – Rob Cheyne, CEO Safelight Security Advisors In this installment of the Safelight lightning talks series, Rob will present the basics of a Cross-site Request Forgery (CSRF).

Main Presentation - Drive-by Pharming with MonkeyFist

Joey Peloquin - Director of Application Security, Fishnet Security

'''June 2010'''

Rob Cheyne Lightning Talk - topic to be announced

Main Presentation - Ryan Barnett The Web Hacking Incident Database (WHID) is a Web Application Security Consortium project dedicated to maintaining a list of web applications related security incidents. Ryan Barnett is director of application security research at Breach Security where he leads Breach Security Labs.

'''May 2010'''

Rob Cheyne Lightning Talk - SQL Injection

Vinnie Liu - Data Exposure, New Approaches to Open Source Intelligence Techniques, and Incident Handling

<br>

'''April 2010'''

Dan Hestad Security Innovation Dan will be talking about his experiences with PCI and web applications, and answering questions about do's and don'ts of acceptable PCI practices in web applications.

'''March 2010'''

Zack Lanier - Disclosure Samsara, or "the endless vulnerability disclosure debate"

http://n0where.org/talks/samsara_20100310.html

http://n0where.org/talks/samsara_20100310.pdf (very large PDF)

<br>

'''February 2010'''

Rob Cheyne of Safelight Security Advisors; New Technology, Same Old Vulnerabilities

<br>

'''January 2010 at Microsoft NERD, Cambridge'''

Josh Abraham, Rapid 7 Technologies

'''December 2009'''

Eric Bender, Cenzic

'''November 2009'''

Jim Weiler, Sr. Mgr. Information Security, Starwood Hotels - Web Application Vulnerability Scanners

Mush Hakhinian, Leader, Application Security Practice, IntraLinks - Secure coding with no money down using SONAR: unleashing the power of open-source code analysis tools

<br>

'''October 2009'''

Paul Schofield, Senior Security Engineer, Imperva - From Rivals to BFF: WAF & VA Unite

<br>

'''September 2009 at CORE Technologies, Boston'''

Paul Asadoorian, Pauldotcom.com

Alex Horan, CORE Security

<br>

'''May 2009'''

Joey Peloquin, Fishnet Security, Secure SDLC: The Good, the Bad and the Ugly [http://www.owasp.org/images/4/48/SecureSDLC-GoodBadUgly.pdf presentation pdf]

<br>

'''March 2009'''

Sabha Kazerooni, Security Compass - Exploit Me tools; Framework Level Threat Analysis

[http://www.owasp.org/images/5/5a/Security_Compass_Exploilt_Me.pdf ExploitMe Document]

[http://www.owasp.org/images/e/ef/Security_Compass_Framework-level_Threat_Analysis.pdf Framework Level Threat Analysis document]

Meeting Pizza Sponsor - Arcot

Arcot is a leader in online fraud prevention, strong authentication and eDocument security. Arcot's solutions are easily deployed, low-cost and extremely scalable, allowing organizations to transparently protect their users from fraud without changing user behavior or requiring expensive hardware.

Arcot can be contacted thru Michael Kreppein, michael.kreppein@arcot.com, 617-467-5200

'''December 2008'''

Brian Holyfield, Gothem Digital Science

Tamper Proofing Web Applications http://www.gdssecurity.com/l/b/2008/12/04/

'''June 2008'''

Jeremiah Grossman; Founder and CTO, Whitehat Security

Appetizer - Hacking Intranets from the Outside (Just when you thought your network was safe) Port scanning with JavaScript

Main Topic - Business Logic Flaws: How they put your Websites at Risk

'''March 2008'''

Chris Eng; Senior Director, Security Research, Veracode

Description – Attacking crypto in web applications

'''December 2007'''

Scott Matsumoto; Principal Consultant, Cigital

Description – You Say Tomayto and I Say Tomahto – Talking to Developers about Application Security

[https://www.owasp.org/images/5/5b/BostonOWASP200712-Cigital.pdf Cigital Presentation]

'''November 2007'''

Tom Mulvehill Ounce Labs

Description – Tom will share his knowledge and expertise on implementing security into the software development life cycle. This presentation will cover how to bring practicality into secure software development. Several integration models will be explored as well as solutions for potential obstacles

[https://www.owasp.org/images/f/f8/Ounce_OWASP_07NOV07ppt.zip Ounce presentation]

<br>

'''October 2007'''

George Johnson, Principal Software Engineer EMC; CISSP

An Introduction to Threat Modeling.

<br>

'''September 2007'''

Day of Worldwide OWASP 1 day conferences on the topic "Privacy in the 21st Century"

'''June 2007'''

Tool Talk - Jim Weiler - WebGoat and Crosssite Request Forgeries

Danny Allan; Director, Security Research, Watchfire

Topic: Exploitation of the OWASP Top 10: Attacks and Strategies

'''March 2007'''

Jeremiah Grossman, CTO Whitehat Security: Top 10 Web Application Hacks of 2006

<br>

'''January 2007'''

Dave Low, RSA the Security Division of EMC: encryption case studies

<br>

'''November 2006'''

<br>

'''September 2006'''

Mike Gavin, Forrester Research: Web Application Firewalls

<br>

'''June 2006'''

Imperva - Application and Database Vulnerabilities and Intrusion Prevention

Jim Weiler - Using Paros Proxy Server as a Web Application Vulnerability tool

<br>

'''May 2006'''

<br>

'''April 2006'''

Dennis Hurst; SPI Dynamics: A study of AJAX Hacking

Jim Weiler; OWASP Boston: Using Paros HTTP proxy, part 1. first meeting with all demos, no powerpoints!

<br>

'''March 2006'''

Mateo Meucci; OWASP Italy [http://www.owasp.org/images/8/8c/Anatomy_of_2_Web_App_Testing.zip Anatomy of 2 web attacks]

Tom Stracener; Cenzic Web Application Vulnerabilities

<br>

'''February 2006'''

Ron Ben Natan; Guardium CTO Database Security: Protecting Identity Information at the Source

<br>

'''January 2006'''

David Low, Senior Field Engineer: RSA Practical Encryption

<br>

'''December 2005'''

Paul Galwas, Product Manager: nCipher [http://www.owasp.org/docroot/owasp/misc/OWASP051207.ppt Enigma variations: Key Management controlled]

<br>

'''November 2005'''

Robert Hurlbut, Independent Consultant [http://www.owasp.org/docroot/owasp/misc/OWASP_Hurlbut_ThreatModelingforWebApplicaitons.zip Threat Modeling for web applications]

<br>

'''October 2005'''

Prateek Mishra, Ph.D. Director, Security Standards and Strategy: Oracle Corp Chaiman of the OASIS Security Services (SAML) Technical Committee - [http://www.owasp.org/docroot/owasp/misc/Federation-Introduction-Overview-01.ppt Identity Federation : Prospects and Challenges]

Ryan Shorter, Sr. System Engineer: Netcontinuum - Application Security Gateways

<br>

'''September 2005'''

Dr. Herbert Thompson, Chief Security Strategist: SecurityInnovation - How to Break Software Security

<br>

'''July 2005'''

Mark O'Neill, CTO: Vordel - [http://www.owasp.org/docroot/owasp/misc/MarkOneill.pdf Giving SOAP a REST? A look at the intersection of Web Application Security and Web Services Security]

'''June 2005'''

Arian Evans, National Practice Lead, Senior Security Engineer: Fishnet Security [http://www.owasp.org/conferences/appsec2005dc/schedule.html Overview of Application Security Tools]

<br>

'''May 2005'''

Patrick Hynds, CTO: Critical Sites - [http://www.owasp.org/docroot/owasp/misc/Passwords-Keys_to_the_Kingdom_Dev_V1.ppt Passwords - Keys to the Kingdom]

<br>

'''April 2005'''

Jonathan Levin - [http://www.owasp.org/docroot/owasp/misc/JLevinRandoms.pdf Of Random Numbers]

Jothy Rosenberg, Founder and CTO: Service Integrity - [http://www.owasp.org/docroot/owasp/misc/JothyRWebSvcsSec.ppt Web Services Security]

<br>

'''March 2005'''

Joe Stagner: Microsoft Let's talk about Application Security

<br>

'''Feb 2005'''

Application Security Inc. PowerPoint slides for the [http://www.owasp.org/docroot/owasp/misc/Anatomy+of+an+Attack.ppt Anatomy of a Database Attack.]

== Local Chapter Information ==

To find out more about the Boston chapter, just join the [http://lists.owasp.org/mailman/listinfo/owasp-boston OWASP Boston mailing list].

The chapter shipping/mailing address is:

OWASP Boston <br />
35 Wachusett Dr <br />
Lexington, MA 02421

== Links ==

[http://www.owasp.org/index.php/Reviews_of_security_podcasts Reviews of security podcasts]

[https://www.owasp.org/index.php/2017_BASC_Homepage Boston Application Security Conference 2017]

[[2016 BASC Homepage|Boston Application Security Conference 2016]]

[[2015 BASC Homepage|Boston Application Security Conference 2015]]

[[2014 BASC Homepage|Boston Application Security Conference 2014]]

[[2013 BASC Homepage|Boston Application Security Conference 2013]]

[[2012 BASC Homepage|Boston Application Security Conference 2012]]

[[2011 BASC Homepage|Boston Application Security Conference 2011]]

[[2010 BASC Homepage|Boston Application Security Conference 2010]]

== Boston OWASP Chapter Leaders ==

'''Contact'''

* Email the [mailto:boston-leaders@owasp.org chapter leaders].

'''President'''

* [mailto:jim.weiler@owasp.org Jim Weiler]

'''Board of Directors'''

* [mailto:lindaleigh.aberdale@owasp.org LindaLeigh Aberdale]
* [mailto:mark.arnold@owasp.org Mark Arnold]
* [mailto:tom.conner@owasp.org Tom Conner]
* [mailto:mike.perez@owasp.org Mike Perez]
* [mailto:roy.wattanasin@owasp.org Roy Wattanasin]
* [mailto:pedro.marcano@owasp.org Pedro Marcano]
* [mailto:Mark.Schlepphorst@owasp.org Mark Schlepphorst]
* [mailto:Ori.Zigindere@owasp.org Ori Zigindere]
__NOTOC__

[[Category:Boston]]
[[Category:OWASP_Chapter]]
[[Category:Massachusetts]]

Boston

2019-05-04T03:36:08Z

Jweiler: /* Chapter Meetings --- Our Fifteenth Year */

{{Chapter Template|chaptername=Boston|extra=Follow @OWASPBOSTON on Twitter. The chapter leader is [mailto:boston@owasp.org Jim Weiler]. The Boston chapter is grateful for support from Constant Contact, Salesforce, Microsoft and Akamai for generously hosting space and their hospitality for various events.

__FORCETOC__

The Chapter would also like to thank our sponsors for their generous support.|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Boston|emailarchives=http://lists.owasp.org/pipermail/owasp-Boston}}

== Chapter Sponsor ==
[[File:SIlogostacked.png|Security Innovation|https://www.securityinnovation.com/]]

[[File:Veracode logo.png|Veracode|https://www.veracode.com/]]

== Boston Application Security Conference ==

[[Image:Boston-Banner-468x60.gif|link=2018_BASC_Homepage]] [[Image:twitter_32.png|link=https://twitter.com/@BASConf]] BASC 2019, the Boston Application Security Conference will take place 8:30am to 6:30pm on Saturday, October 19th at Microsoft, 5 Wayside Road, Burlington, MA. [[2018 BASC Homepage|Read more]]

== Chapter Meetings --- Our Fifteenth Year ==

We now use [http://www.meetup.com/owaspboston/ meetup] to organize meetings.

We meet whenever a speaker and a venue have available dates, 6:30 to 9 pm.

Everyone is welcome to come to any meeting, there is no signup or joining criteria, just come if it sounds interesting. You can join the OWASP Boston Google group at https://groups.google.com/a/owasp.org/forum/#!forum/boston-chapter. This list is very low volume (2 - 3 emails/month); it is used to remind people about each monthly meeting, inform about local application security events and special chapter offers.


Upcoming Meetings

CMD+CTRL Web Application Hacking Cyber Range May 22, 2019 @ 6:00-9:00pm Athena Health Watertown

Want to test your skills in identifying web app vulnerabilities? Join OWASP Boston, Athena Health and Security Innovation as members compete in CMD+CTRL, a web application cyber range where players exploit their way through hundreds of vulnerabilities that lurk in business applications today. Success means learning quickly that attack and defense is all about thinking on your feet. Standard capture the flag using network and operating attack skills will not be much use here; understanding the OWASP Top 10 risks will help you find the vulnerabilities.

For each vulnerability you uncover, you are awarded points. Climb the interactive leaderboard for a chance to win prizes! CMD+CTRL is ideal for development teams to train and develop skills, but anyone involved in keeping your organization’s data secure can play - from developers and managers and even CISOs.

YOU CAN ONLY REGISTER ON THE SECURITY INNOVATION REGISTRATION SITE AT THIS LINK - <nowiki>https://web.securityinnovation.com/athenahealth2019</nowiki>

Register early to reserve your spot !

Just bring a laptop. Pizza and soda will be provided.

Venue/Location of the event:

Athena Health

311 Arsenal St.

Watertown, MA 02472

See the attached map -

Park in only P2 visitor lot or in garages P1 and P3. Parking is free.

The main lobby door is at “S1” shuttle pickup icon.

Enter the lobby and sign in at the front desk to pick up credentials.

Directions to the event room will be provided at that time

=== Upcoming Training ===
TBD

=== Past Meetings ===

''January 29th, 2019'' - Cambridge [https://web.securityinnovation.com/owaspboston2019 Partnered with Security Innovation]

Location: [https://goo.gl/maps/w11GUuJJAbo Quick Base office]

5PM- '''Just bring your computer and evil inner-doer and you are ready to roll!'''

Security Innovation is teaming up with OWASP Boston to offer attendees a fun "find the vulnerabilities" game - CMD+CTRL Cyber Range - that shows how hackers break into websites and teaches the importance of secure coding habits.

The CMD+CTRL Cyber Range we will be using is called ShadowBank, a banking website where players compete to find vulnerabilities, score points, and move up the leaderboard. Leveraging cheat sheets, attack tables, and expert led training sessions, platers take their shot at stealing money, manipulating share prices, and conducting other nefarious acts.

''June 14th, 2017'' - Burlington [https://www.meetup.com/owaspboston/events/240033562/ Meetup]

Location: [https://maps.google.com/maps?f=q&hl=en&q=5+Wall+St.%2C+Burlington%2C+MA%2C+us SalesForce (was Demandware) 5 Wall St., Burlington, MA]

Everyone should report to Akamai 90 Broadway in the lobby and indicate about the Meetup. Someone form the staff will escort them to the 12th floor.

5:30 - 6:15 - '''Chat, Chew and Brew'''

6:15 - 6:45 '''News, Announcements'''

Chapter and OWASP events and news, audience announcements, questions, application security news(Google and Symantec certs, HTML5, Chrome features, SDLC and Microservices, others?)

7:00 pm ''' Is RASP Ready?'''

Runtime Application Self-Protection is overhyped, according to many analysts and pundits. RASP promises applications that protect themselves - which sounds impossible - how can an application possibly protect itself? An agent that sits inside the app sounds like a deployment nightmare at worst, and a drain on the app at best. What’s the reality? Where are we now and what have we learned?

We’ve seen deployment successes and failures, and we will draw from those specific experiences to describe:
Where does RASP work?
* What applications are well-suited for RASP?
* What types (organizational structure, culture, or skillset) of organizations are well-suited for RASP?

What is the reality of RASP?
* Is RASP a deployment model or a feature set?
* How mature is RASP? Is it an over-hyped immature space, enterprise-ready, or somewhere in between?
* Which RASP capabilities do organizations use? And how do they validate those capabilities in their own environments?
* Can RASP replace the WAF?

We will conclude, not with a sales pitch, but some lessons learned on: the three must have attributes for RASP, some suggestions on good candidates for RASP – both types of teams and types of applications, and finally - if, how, and when to get started.

''Speaker'': Michael Feiertag, CEO and Co-Founder, tCell
Before co-founding tCell at the end of 2014, Michael led a string of successful products – most recently as head of products at Okta, and prior to that, as technology director at Blue Coat. Prior to Blue Coat, Michael held product management, engineering, and sales positions at several start-ups. Michael holds a B.S. from The University of Chicago, and an M.S. from the University of Maryland

'''May 2, 2017''' - Burlington [https://www.meetup.com/owaspboston/events/239130768/ Meetup]

Location: [https://maps.google.com/maps?f=q&hl=en&q=5+Wall+St.%2C+Burlington%2C+MA%2C+us SalesForce (was Demandware) 5 Wall St., Burlington, MA]

Everyone should report to Akamai 90 Broadway in the lobby and indicate about the Meetup. Someone form the staff will escort them to the 12th floor.

5:30 - 6:15 - '''Chat, Chew and Brew'''

6:15 - 6:45 '''News, Announcements'''

Chapter and OWASP events and news, audience announcements, questions, application security news(Google and Symantec certs, HTML5, Chrome features, SDLC and Microservices, others?)

6:50 pm '''Random Number Generation - Lava Lamps, Clouds, New Standards and the IoT - Richard Moulds'''

The SANS Institute recently listed "Weak random number generators" as one of the 7 most dangerous security techniques to watch in 2017. But how do you really know how good your random numbers are? Virtualization and IoT make things worse and new standards are a wake-up call. Random numbers are the basis of security for all cryptography, yet they are often taken for granted. Without entropy, crypto is just math.

Learn why random numbers are so hard to generate and validate, compare different technologies in use today across virtualized environments, and discuss operational steps to take the risk out of random numbers and help secure cryptosystems even into the era of quantum computers.

''Speaker'': Richard Moulds, General Manager of Whitewood Security, has spoken at RSA 2017 and at several OWASP chapter events in New York, Chicago and Austin. Richard has over 20 years of experience in the area of cryptography and encryption.

'''November 2, 2016''' - Cambridge [https://www.meetup.com/owaspboston/events/234648485/ Meetup]

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 90 Broadway, Cambridge, MA 02142 (down the street from the usual location)

Everyone should report to Akamai 90 Broadway in the lobby and indicate about the Meetup. Someone form the staff will escort them to the 12th floor.

6:30 '''News, Announcements'''

7:00 '<nowiki/>''Advanced Persistent Legal Threats''' - '''''<nowiki/>'''William Gamble, JD, LLM, EMBA'''

Abstract: Good cyber security can protect IT infrastructure against many attacks. Because of the difficulty in monetizing cyber thefts, the direct loss of a breach can be limited. However, the legal costs, both from government agencies and plaintiffs, can be far greater. The legal landscape, both in the US and internationally is changing as fast if not faster than the technology.

Bio: I am a lawyer and a member of the Florida Bar.I used to practice tax, securities and banking law. I have written three books and spoken around the world on the economic efficiency of legal and regulatory infrastructures specifically in emerging markets like China. Over the past two years, I have immersed myself in cyber security. I now hold the CompTIA A+, Network+, and Security+. I will take the CASP next month. Besides keeping up with the regulations, I am studying incident response and auditing. I am also working toward my health care law certification. My hero is Dr. Johannes Ullrich.

'''September 28, 2016''' - Burlington - [http://www.meetup.com/owaspboston/events/233921522/ Meetup]

Location: [https://www.google.com/maps/place/5+Wall+St,+Burlington,+MA+01803/@42.4877956,-71.1904085,17z/data=!3m1!4b1!4m5!3m4!1s0x89e3758106c4cb55:0xc155e97a6d34883e!8m2!3d42.4877956!4d-71.1882198?hl=en Demandware] at 5 Wall St., Burlington, MA

6:00 '''News, Announcements'''

6:15 '''OWASP Top 10 #1 - Injection Flaws'''

Jim Weiler will discuss XML External Entity Injection flaws; how it works, how to prevent, code examples.

6:45 '<nowiki/>''From the Frontlines of RASP Adoption''' - '''''<nowiki/>'''Goran Begic, VP of Product, IMMUNIO'''

Runtime Application Self-Protection (RASP) is one of the newest technologies coined by Gartner and it is in early stages of adoption in the industry. It promises dynamic defense and automatic mitigation of vulnerabilities in web applications.

This presentation is a summary of experiences from several dozens of commercial evaluations and early adoptions in production that took place this year and provides some examples of situations and challenges that are not specific to any individual vendor. In this talk Goran will provide an overview of buying criteria and evaluation requirements across different industries and some typical pitfalls that can slow down adoption.

After the introduction and a brief reminder on the technology Goran will invite audience to participate in discussion about organizational requirements for adoption and operationalization of RASP.

Questions for discussion:

My application is under attack.
*What actions should I take?
*Who owns the response?
*Which attacks should I respond to and which ones can I ignore?
*How to get started with mitigation provided by technology?
*Does RASP fit with DevOps?
*Does RASP help with remediation?

What this presentation is not: This is not a product pitch in any way. Evaluation criteria, comparison of RASP with IAST and other security technologies, personal experiences and examples discussed in this talk are generally applicable to all RASP solutions.

Key takeaways:

At the end of the presentation you will:
*get a better understanding of requirements for evaluation of RASP and its use cases,
*if you can pull a successful evaluation alone, or if you will need participation of other groups / teams
*learn about critical criteria for success of RASP in production
*how this criteria different relative to appsec testing tools.

'''September 7, 2016''' - Cambridge - [http://www.meetup.com/owaspboston/events/229223967/ Meetup]

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 150 Broadway, Cambridge, MA 02142 (aka 8 Cambridge Center)

6:30 '''News, OWASP tools, documents review'''

7:00 '''Docker Containers and Application Security''' - '''Tsvi Korren'''

Docker containers are transforming the way applications are developed and deployed. Closely tied to DevOps and Continuous Delivery, containers introduce both risks and opportunities to security management in Web applications. This talk will introduce the basic concepts of containers, how companies use them today and how to support this technology while elevating the security posture of your application stacks.

Tsvi Korren, CISSP, has been an enterprise IT professional for 20 years with background in business process consulting in large organizations. Most recently at CA Technologies, he worked across verticals in government, retail, financial institutions and healthcare to implement compliance and security processes, from Identity and Access to Host and Server Controls. Tsvi is currently the director of technical services at Aqua, concentrating on building bridges between DevOps and Security.

'''June 8, 2016''' - Burlington - [http://www.meetup.com/owaspboston/events/230842887/ Meetup]

Location: [https://www.google.com/maps/place/5+Wall+St,+Burlington,+MA+01803/@42.4877956,-71.1904085,17z/data=!3m1!4b1!4m5!3m4!1s0x89e3758106c4cb55:0xc155e97a6d34883e!8m2!3d42.4877956!4d-71.1882198?hl=en Demandware] at 5 Wall St., Burlington, MA

6-6:30 '''News, announcements, job postings, etc. '''

6:30-7 '''Introduction to SQL Injection - Jim Weiler'''

7:00 '''Computer Science Curricula’s Failure - What Should We Do Now?''' - '''Ming Chow & Roy Wattanasin'''

We are still facing the same security vulnerabilities from over a decade ago. The problems are not going away anytime soon and a reason is because Computer Science curricula are still churning out students who are not even exposed to security. This talk will address the lack of emphasis on information security in Computer Science curricula, how CS curricula have an obligation, how to gradually fix the problem by integrating security into many Computer Science undergraduate and graduate classes, and success stories from students. This talk will also discuss what Tufts and Brandeis are currently working on to further address the security education problem by creating a joint cyber security and policy program that spans multiple departments. Additional points and feedback from the audience are encouraged to help with the issue. All are encourage to attend to submit your feedback to help!

Presenters:

Ming Chow - @0xmchow

Ming Chow is a Senior Lecturer at the Tufts University Department of Computer Science. His areas of work are in web and mobile engineering and web security. He was a web application developer for ten years at Harvard University. Ming has spoken at numerous organizations and conferences including the High Technology Crime Investigation Association - New England Chapter (HTCIA-NE), the Massachusetts Office of the Attorney General (AGO), John Hancock, OWASP, InfoSec World, DEF CON, Intel, SOURCE Conference, and BSides Boston. He was a mentor for a Proving Ground speaker at BSides Las Vegas in 2014 and 2015.

Roy Wattanasin - @wr0

Roy Wattanasin is an adjunct faculty at Brandeis University in both the Health and Medical Informatics and Information Security graduate programs. He spends most of his time leading, teaching and developing information security programs, finding vulnerabilities, performing incident response and working on many projects. Roy has spoken at many conferences including RSA, ISSA International, Source Conference, Braintank, Cyber Security World, OWASP and the Security BSides conferences. He is also a healthcare information security professional. He was a mentor for a Proving Ground speaker at BSides Las Vegas in 2015.

'''May 4, 2016''' - Cambridge - [http://www.meetup.com/owaspboston/events/229788205/ Meetup]

Location: Slightly different [http://www.akamai.com/html/about/locations.html Akamai] location: 90 Broadway, Cambridge, MA 02142 between Meadhall and the Mariott

6:30 '''News, OWASP tools, documents review'''

7:00 '''The ABCs of Source-Assisted Web Application Penetration Testing With OWASP ZAP''' - '''Dan Cornell'''

There are a number of reasons to use source code to assist in web application penetration testing such as making better use of penetration testers’ time, providing penetration testers with deeper insight into system behavior, and highlighting specific sections of so development teams can remediate vulnerabilities faster. Examples of these are provided using the open source ThreadFix plugin for the OWASP ZAP proxy and dynamic application security testing tool. These show opportunities attendees have to enhance their own penetration tests given access to source code.

This presentation covers the “ABCs” of source code assisted web application penetration testing: covering issues of attack surface enumeration, backdoor identification, and configuration issue discovery. Having access to the source lets an attacker enumerate all of the URLs and parameters an application exposes – essentially its attack surface. Knowing these allows pen testers greater application coverage during testing. In addition, access to source code can help to identify potential backdoors that have been intentionally added to the system. Comparing the results of blind spidering to a full attack surface model can identify items of interest such as hidden admin consoles or secret backdoor parameters. Finally, the presentation examines how access to source code can help identify configuration settings that may have an adverse impact on the security of the deployed application.

Dan Cornell is a globally recognized application security expert, Dan Cornell holds over 15 years of experience architecting, developing and securing web-based software systems. As the Chief Technology Officer and a Principal at Denim Group, Ltd., he leads the technology team to help Fortune 500 companies and government organizations integrate security throughout the development process. He is also the original creator of ThreadFix, Denim Group's industry leading application security program management platform. Cornell was Principal Investigator as Denim Group researched and developed the Hybrid Analysis Mapping (HAM) technology that lies at the heart of ThreadFix, through a Small Business Innovation Research (SBIR) contract with the Department of Homeland Security's Science and Technology Directorate.

More information at: http://www.denimgroup.com/about_team_dan.html

'''April 6, 2016''' - Cambridge - [http://www.meetup.com/owaspboston/events/229223967/ Meetup]

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 150 Broadway, Cambridge, MA 02142 (aka 8 Cambridge Center)

6:30 '''News, OWASP tools, documents review'''

7:00 '''Runtime Application Self-Protection (RASP) Tools''' - '''Kunal Anand'''

This talk will highlight the latest in AppSec and dive into a different kind of solution called Runtime Application Self-Protection (RASP). We'll also explore a new methodology called language theoretic security (LANGSEC) and explain how it can outperform existing approaches like pattern matching, regular expressions, etc. This talk will lay the foundation via informal and formal theory how lexers, tokenizers and parsers work. We’ll move onto constructing an open source toolchain to analyzing data and exploring interactive data visualizations. Along the way, we’ll cover performance tradeoffs and discuss the challenges of modern application security.

Kunal Anand is the co-founder and CTO of Prevoty, a runtime application security platform. Prior to that, he was the Director of Technology at the BBC Worldwide, overseeing engineering and operations across the company’s global Digital Entertainment and Gaming initiatives. Kunal also has several years of experience leading security, data and engineering at Gravity, MySpace and NASA’s JetPropulsion Laboratory. His work has been featured in Wired Magazine and Fast Company. Kunal received a B.S. from Babson College.

=== Past Training ===

'''March 16, 2016''' - Burlington - [http://www.meetup.com/owaspboston/events/229156529/ Meetup]

Location: Demandware, Burlington.

6:00 '''News, OWASP tools, documents review'''

6:30 '''Software Security by the Numbers''' - '''Chris Eng'''

Deep dive into data we’ve collected about the state of software security in 2016
* Based on scans of 200,000+ applications over an 18-month period
* How different industries and programming languages compare to one another
* Vulnerability remediation habits and patterns
* Three characteristics of a successful AppSec program

Chris Eng is vice president of research at Veracode. In this role, he leads the team responsible for integrating security expertise into all aspects of Veracode’s technology. Throughout his career, he has led projects breaking, building, and defending web applications and commercial software for some of the world’s largest companies. Chris is a frequent speaker at premier industry conferences, where he has presented on a diverse range of topics, including cryptographic attacks, agile security, mobile application security, and security metrics. He has been interviewed by Bloomberg, Fox Business, CBS, and other media outlets worldwide.

'''January 26, 2016''' - Waltham - [http://www.meetup.com/owaspboston/events/228202040/ Meetup]

Location: Constant Contact, Waltham. Trapelo Rd. exit from Rt. 128, toward Lincoln. The parking lot entrance is on the right, at the first traffic light. Drive around to the front of the office complex, facing the highway. Enter under the clock tower. Park in the front of the building and enter in the main building lobby, continue down the hallway and you will see the innovation center, enter in the large glass doors.

7:00 '''News, OWASP tools, documents review'''

7:20 '''What Security Testing Tools Miss'''

Black Duck Software presents - Static analysis, dynamic analysis, and other testing tools are all essential weapons against adversaries. But for the 80%+ of companies worldwide that use open source software in their application development these tools are ineffective in identifying and mitigating open source security risks . This presentation will cover:

The value of static and dynamic tools, and where they best fit in the Secure Development Lifecycle

Why these tools are not useful in identifying known vulnerabilities in open source components

Controls development and security professionals can deploy to select, detect, manage and monitor open source for existing and newly disclosed vulnerabilities

Food will be provided by Constant Contact.

'''November 2015''' - Cambridge - [http://www.meetup.com/owaspboston/events/226394218/ Meetup]

When: Wednesday, November 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 150 Broadway
Cambridge, MA 02142 (aka 8 Cambridge Center)

6:30 '''News, views, announcements, conversation'''

7:00 '''Interactive Discussions (Come and ask your questions!)'''

Attendee interaction is always mentioned as a high value at meetings and was great at the MetroWest meetings, so we're doing that at Akamai this month. Some discussion starters so far: SSL certificate impacts from CA/Browser alliance decisions and SHA1 weakness; mutual (client) SSL, javascript client and server side; what the heck is threat intelligence, dev ops and faster secure SDLC.

'''July 2015''' - Metrowest

When: Wednesday, July 20, 7:00 pm

Location: Constant Contact, Innovation Center, Reservoir Place, 1601 Trapelo Road, Waltham, MA 02451

7:00 '''News, views, announcements, conversation'''

7:30 '''Access in Maliceland - Risk Based Access Control''' - '''Gunnar Peterson'''

John Lambert observed attackers win because while defenders think in lists, attackers think in graphs. Access control systems divide the system a priori into secure and insecure states. But that’s only worth the paper its printed on. A Attackers see the system as it is, for attackers, the access control scheme is the beginning of the game not the end. Determined attackers seek out access control models and then find holes that they can leverage. Access control systems that purport to protect the system are built on assumptions from which reality diverges. Application security needs a new approach to access control- adding feedback loops for risk based decisions, fine-grained, dynamic access control.

Security is a business with a very long list of issues and requirements. The spreadsheets are miles long. This makes it essential to find reusable solution patterns that can address multiple problems.This presentation looks at both medium term improvements and code examples to improve access control decisions and overall security today

Gunnar Peterson ([https://twitter.com/oneraindrop @oneraindrop]) focuses on security architecture consulting and training. Experience includes Associate Editor for IEEE Security & Privacy Journal, a Microsoft MVP for App security, an IANS Research Faculty member, a Securosis Contributing Analyst, and a Visiting Scientist at Carnegie Mellon Software Engineering Institute. He maintains a popular information security blog at http://1raindrop.typepad.com.

'''July 2015''' - Cambridge

When: Wednesday, July 8, 6:30 pm ''NOTE: It's the second Wednesday this month.''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''Interactive Discussions (Come and ask your questions!)'''

'''June 2015'''

When: Wednesday, June 3, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''Put Down the Megaphone: Effective Security Advocacy Without the Shouting''' - '''Darren Meyer'''

10 years’ experience in the InfoSec community--including work with organizations in many verticals, in sizes ranging from startups to Fortune 50 enterprises, leading Application Security teams, building and delivering security instruction to developers, managers, and InfoSec professionals—has taught me the importance of crafting advocacy for different audiences. In this talk, I share my experiences in learning to be an effective advocate with three key audiences: developers, management, and non-technical staff.

Darren is an Application Security advocate and researcher, technology hobbyist, and maker. He loves to learn, teach, nerd out, and inflict terrible puns on people. His background includes logistics, software development, and an assortment of information security roles including leading AppSec programs and professional security instruction targeting developers, managers, and InfoSec professionals.

'''May 2015'''

When: Wednesday, May 6, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''How the crowd is discovering critical vulns missed by traditional methods''' - '''Leif Dreizler'''

State of the art security programs are turning to bug bounties to leverage a vast array of skill-sets and knowledge. Learn why these programs work, when to deploy them, and how you can bring these new application security testing capabilities into your own organization. The speaker will discuss real world examples from bug bounties and focus on cases where business logic flaws and high priority vulnerabilities were found ... even with existing security testing processes in place.

Attendees will learn:

Testing methods deployed by our crowd that help them find bugs the scanners miss

Examples of the high quality of bugs our crowd is finding, including P1'sTrends which vulnerability types are found most often and whyWhat is the ROI on the pay for performance modelWhere does the SDLC merge into crowdsourced testing

Leif Dreizler is a Senior Security Engineer at Bugcrowd, the innovator in crowdsourced security testing for the enterprise. Prior to joining Bugcrowd, Leif was a Senior Application Security Engineer at Redspin, performing application security assessments. During his time at Redspin he also served as the Application Team Lead, liaising with clients at the engineering and sales level. He has also made minor contributions to the Firebug project. Leif attended the University of California, Santa Barbara where he studied Computer Science. Leif recently spoke to the NYC Security Meet-up group.

'''April 2015'''

When: Wednesday, April 1, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

Jim Weiler Will show some actual examples and patterns of SQL Injection attempts

7:00 '''Are You An Imposter? Me too!''' - '''Patrick Laverty'''

Many people in the information security field feel like a fraud, or an imposter. In reality, we often know far more, and are capable of far more than we believe we do. There is so much to know and we constantly hear about the latest groundbreaking research done by others, which makes us feel less important or worthy. Let’s talk about what Imposter Syndrome is, its prevalence, and then we can start to realize just how capable we are and go forward with the confidence in the field.

'''March 2015'''

When: Wednesday, March 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''Prioritizing Web Application Vulnerabilities – A Hacker’s Perspective''' - '''Nick Silver'''

The best application risk models capture not only the technical risk factors, but also the business context in which an asset lives. Traditionally, this is done by auditing application owners on an array of questions in order to properly classify the asset and its data – but that takes time which could be better spent elsewhere. We interviewed dozens of hackers and asked them which vulnerabilities they would look for first depending on the type of attack they wanted to carry out. We’ll walk through several examples of how to use this data as a shortcut means for prioritizing risk without the need for any pesky audit questionnaires.

Nick Silver is a Senior Solutions Architect with WhiteHat Security. He is responsible for translating business requirements into technical ones and assisting businesses in implementing web security programs. Previously, Nick led a team in WhiteHat’s Threat Research Center where they were responsible for testing more than 2,000 of their customers’ websites for vulnerabilities.

'''February 2015'''

When: Wednesday, February 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News review, announcements''' - '''Jim Weiler'''

7:00 '''Incident Response and Web Application Security - Stories from the Trenches''' - '''Fred House and Joe Ceirante'''

Mandiant has conducted numerous incident response engagements throughout its history, including a record number of 200 incidents in 2014. Mandiant consultants Fred House and Joe Ceirante will discuss case studies and trends Mandiant has observed in relation to web application security.

Topics will include the types of threat actors that target web applications, the techniques they use to compromise web applications, and the activities they perform once inside the network. Techniques for detecting and mitigating web compromises will also be reviewed. All content will be derived from the real-world compromises that Mandiant has investigated.

'''January 2015'''

When: Wednesday, January 7, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News review, risk analysis of Poodle''' - '''Jim Weiler'''

7:00 '''How a Hacker Views Your Web Site''' - '''Patrick Laverty'''

''The most popular presentation of BASC 2014''

As defenders, we have to be right 100% of the time where an attacker only needs to be right once. The attack surface of a modern web site is incredibly large and we need to be aware of all of it. Additionally, individual attacks may not always be effective but sometimes using them together can gain the desired effect. In this talk, we’ll take a look at the whole attack surface for a typical web site and the various ways that an attacker will use to compromise a site.

'''December 2014'''

When: Wednesday, December 3, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News and Views You Can Use and Abuse''' - '''Jim Weiler'''

* Some thoughts and analysis on some current app security news and other stuff
* Adobe password breach
* Reducing Web Application Firewall SQL injection false positives

7:15 '''Swift and Security''' - '''Ming Chow'''

Apple is pushing its new programming language Swift for iOS development and for many good reasons. This talk will discuss what the language has right in terms of security, the old and new security pitfalls, and what developers need to be aware of moving forward with using the new language. The fact to the matter is, iOS isn't going away, iOS developers will need to learn and use Swift, and there will be a big rush of Swift-based apps: we might as well learn how to do it right the first time around.

Ming Chow is an Instructor at the Department of Computer Science, Tufts University. Ten years of web development experience.
Specialties: Web and Mobile Development, Web and Mobile Security

'''July 2014'''

Topics: '''Grails Security''' and '''Validating Cross-Site Scripting Vulns with xssValidator'''

Presenters: '''Cyrus Malekpour''' and '''John Poulin'''

When: Tuesday, July 8, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic 1: ''Grails Security''

Grails is a framework developed for Groovy in the vein of Rails for Ruby. It provides a lot of features for web app security, but does it do enough? What might you need to implement yourself, and what might be provided? This presentation will discuss tips on securing Grails applications, including tools that the framework provides by default for security. It'll also discuss several shortcomings in the current toolset, and how you can avoid them.

Cyrus Malekpour (@cmalekpour) is currently interning at nVisium, working on web app development and security. He's currently an undergraduate student at the University of Virginia, where he's studying computer science with an emphasis on security and backend development.

Topic 2: ''Validating Cross-Site Scripting Vulns with xssValidator''

xssValidator is a tool developed to automate the testing and validation of Cross-Site Scripting (xss) vulnerabilities within web applications. Automated scanners tend to report large amounts of false-positives, and as consultants we're forced spending our time trying to verify these findings. xssValidator leverages scriptable web-browsers such as PhantomJS and Slimer.js to automatically validate these findings.

John Poulin is an application security consultant for nVisium who specializes in web application security. He worked previously as a web developer and software engineer that focused on building multi-tier web applications. When he's not hacking on web apps, John spends his time building tools to help him hack on web apps! You can find him on twitter: @forced_request and on myspace: REDACTED.

'''June 2014'''

Topic: '''Training: SQL Injection and the OWASP Zed Attack Proxy (ZAP)'''

Presenters: '''Rob Cheyne and Jim Weiler'''

When: Wednesday, June 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 - general networking, news discussion, announcements.

7:00 - main presentations

The June 4th meeting will be the second in our series of 2014 training meetings. Rob Cheyne will continue explaining and exploring SQL Injection by conducting an actual injection attack.

This will be a demo-based discussion to get into the mindset of an attacker, and show how an attacker goes after a site. Demo will include:

* BurpProxy demo
* Common authentication flaws
* SQL Injection Demo that shows the process and how it builds to a full compromise

'''Rob Cheyne''' is currently CEO of Big Brain Security. In addition to security consulting for Fortune 500 customers, he was the author of LC4, a version of the award-winning L0phtCrack password auditing tool, and he also worked on the code scanning technology that was eventually spun off as Veracode. Rob was at @stake from the very first customer all the way through to the $50M acquisition by Symantec.

'''Jim Weiler''' will introduce the OWASP Zed Attack Proxy (ZAP). This is a very powerful free OWASP intercepting proxy that lets you see, analyze, change, replay etc. every browser request and response, analyze your session, scan and attack web sites, save the results and run reports. We can't cover all the functionality but we'll show some practical tips and techniques.

Pizza, salad and soda courtesy of Akamai

'''March 2014'''

Topic: '''Training: SQL Injection, WebGoat, Cross Site Request Forgery'''
Presenter: '''Benjamin Lerner'''
When: Wednesday, March 5, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

There will be three training sessions:

One will be on SQL Injection - intro, detection, prevention, scanning and false positives. This is the most serious web application vulnerability.

The second will be on OWASP WebGoat. WebGoat is a deliberately insecure web application maintained by OWASP designed to teach web application security lessons. You can install and practice with WebGoat in either J2EE or in ASP.NET. In each lesson, users must demonstrate their understanding of a security issue by exploiting a real vulnerability in the WebGoat applications. There are hints and 39 different lesson plans on various vulnerabilities and technologies. We won't cover all of them of course!

The third will be on Cross Site Request Forgery - not a hack really, it's just the way the web works. But it causes apps to do legitimate things that you didn't ask them to do.

Pizza and drinks provided by Akamai.

'''January 2014'''

When: Wednesday, January 8, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic: '''JavaScript Verification: From Browsers to Pages'''

Modern web browsers implement a "private browsing" mode that is intended to leave behind no traces of a user's browsing activity on their computer. This feature is in direct tension with support for *extensions*, which let users add third-party functionality into their browser. I will discuss the scope of this problem, present our approach to verifying extensions' compliance with private browsing mode, and sketch our findings on several real, third-party extensions. I will then briefly describe the toolkit underlying our approach, and end with a sketch of a newer project, adapting this approach to the very different-seeming problem of statically catching errors when using the jQuery library.

Presenter: '''Benjamin Lerner'''

Benjamin Lerner has just completed a post-doctoral research position in the PLT group at Brown University, and is now a lecturer at Northeastern University. His research examines the challenges of analyzing client-side web programming, from the behavior of web pages down through the semantics of the browser. He received a PhD in Computer Science from the University of Washington in 2011, building a platform to analyze conflicts between browser extensions, and a B.S. in Computer Science and Mathematics from Yale University.

'''November 2013'''

When: Wednesday, November 6, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic: '''Attacking iOS Applications'''

Slides: [http://www.slideshare.net/kfosaaen/i-os-gcandpb On slideshare]

This presentation will cover the basics of attacking iOS applications (and their back ends) using a web proxy to intercept, modify, and repeat HTTP/HTTPS requests. (The proxy used during research was Burp; however, any HTTP intercepting proxy such as OWASP ZAP could be used) From setting up the proxy to pulling data from the backend systems, this talk will be a great primer for anyone interested in testing iOS applications at the HTTP protocol level. There will be a short (2 minute) primer on setting up the intercepting proxy, followed by three practical examples showing how to intercept data headed to the phone, how to modify data heading to the application server, and how to pull extra data from application servers to further an attack. All of these examples will focus on native iOS apps (Game Center and Passbook) and/or functionality (Passbook Passes).

Presenter: '''Karl Fosaaen'''

Karl is a senior security consultant at NetSPI. This role has allowed Karl to work in a variety of industries, including financial services, health care, and hardware manufacturing. Karl specializes in network and web application penetration testing. In his spare time, Karl helps out as an OPER at THOTCON and a swag goon at DEF CON.

'''October 2013'''

When: Wednesday, October 2, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic: '''Abusing NoSQL Databases'''

The days of selecting from a few SQL database options for an application are over. There is now a plethora of NoSQL database options to choose from: some are better than others for certain jobs. There are good reasons why developers are choosing them over traditional SQL databases including performance, scalabiltiy, and ease-of-use. Unfortunately like for many hot techologies, security is largely an afterthought in NoSQL databases. This short but concise presentation will illustrate how poor the quality of security in many NoSQL database systems is. This presentation will not be confined to one particular NoSQL database system. Two sets of security issues will be discussed: those that affect all NoSQL database systems such as defaults, authentication, encryption; and those that affect specific NoSQL database systems such as MongoDB and CouchDB. The ideas that we now have a complicated heterogeneous problem and that defense-in-depth is even more necessary will be stressed. There is a common misconception that SQL injection attacks are eliminated by using a NoSQL database system. While specifically SQL injection is largely eliminated, injection attack vectors have increased thanks to JavaScript and the flexibility of NoSQL databases. This presentation will present and demo new classes of injection attacks. Attendees should be familiar with JavaScript and JSON.

Presenter: '''Ming Chow'''

Ming Chow (@tufts_cs_mchow) is a Lecturer at the Tufts University Department of Computer Science. His areas of work are in web and mobile engineering and web security. He teaches courses largely in the undergraduate curriculum including the second course in the major sequence, Web Programming, Music Apps on the iPad, and Introduction to Computer Security. He was also a web application developer for ten years at Harvard University. Ming has spoken at numerous organizations and conferences including the High Technology Crime Investigation Association - New England Chapter (HTCIA-NE), the Massachusetts Office of the Attorney General (AGO), John Hancock, OWASP, InfoSec World (2011 and 2012), DEF CON 19 (2011), the Design Automation Conference (2011), Intel, and the SOURCE Conference (Boston 2013). Ming's projects in information security include building numerous CTF challenges, Internet investigations, HTML5 and JavaScript security, and Android forensics.

'''September 2013 - Joint Meeting with [http://www.meetup.com/Boston-cloud-services/ Boston Cloud Services]'''

When: Tuesday, September 10, 6 pm

Location: Microsoft NERD Center ''(not our usual location)''

'''Note: This is a joint meeting. Please register at [http://www.meetup.com/Boston-cloud-services/ the Boston Cloud Services meetup page] if you plan to attend.'''

There will be two presentations at this meeting:

Topic: '''People Centric Security (PCS)'''

Presenter: '''Nick Stamos'''

People Centric Security (PCS) is a new security model, presented as part of Gartner's Maverick Research 2 year ago. PCS is well suited for Cloud Business/Consumer services such as Dropbox, Google Drive, SkyDrive, etc. PCS enables users to have what they desire, and provides enterprises what they require for data governance and compliance. Nick Stamos co-founded his fourth company, nCrypted Cloud in July of 2012. His past startups include Verdasys, Phase Forward (IPO FY2004, $685M Oracle Acquisition 2010), and Amulet. He studied at Tufts University where he received a BSEE and MSEE.

Topic: '''SSL Certs'''

Presenter: '''Jim Weiler'''

Practical experiences with issuing and risk assessing SSL certs for enterprise applications on a cloud provider: who creates the CSR, how do you protect the private key on the cloud server, certs on cloud provider managed load balancers vrs 3rd party managed app servers, roles and responsibilities of cloud IT, 3rd party developer IT, enterprise IT and service providers. Jim Weiler is Application Security Architect at Starwoods Hotels and the Chapter Leader of OWASP Boston.

'''July 2013 - Doubleheader!'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, July 10, 6:30 pm

Topic: '''RailsGoat'''

Presented by: '''Ken Johnson'''

Abstract: While working to secure rails applications in a truly Agile development environment, it became clear that the Rails and Ruby ecosystem needed attention from the security community in the form of free and open training, and the events that have transpired within the last few months have only reinforced that belief. [http://railsgoat.cktricky.com/ RailsGoat] is an attempt to bring attention to both the problems that most frequently occur in Rails as well as the solutions for remediation. To accomplish this, we've built a vulnerable Rails application that aligns with the OWASP Top 10 and can be used as a training tool for Rails-based development shops.

Topic: '''PhoneGap on Android'''

Presented by: '''Jack Mannino'''

Abstract: PhoneGap is a widely used framework that allows developers to rapidly build cross-platform mobile applications using HTML5, JavaScript, and CSS. Using PhoneGap plugins, developers can call native platform APIs from browser-like applications using JavaScript. This approach introduces vulnerabilities that are not typically as prevalent within native Android applications, warranting a fresh look at the way we view mobile applications. In this presentation, we will take a deep look at the Android implementation of the framework and we will examine the overall attack surface for applications. Real-world examples of vulnerable applications will be demonstrated as well in order to provide context, entertainment, and enjoyment.

About the Speakers:

Ken Johnson is the former Manager of LivingSocial.com's application security team where he built their security program before leaving for his true home as the CTO of nVisium Security, a VA-based application security company. Ken is the primary developer of the Web Exploitation Framework and contributes to other open source application security projects as often as time permits. He has spoken at AppSec DC 2010 and 2012, OWASP NoVA and Phoenix chapters, Northern Virginia Hackers Association (NoVAH) and is a contributor to the Attack Research team.

Jack Mannino is the CEO of nVisium Security, a VA-based application security company. At nVisium, he helps to ensure that large corporations, government agencies, and software startups have the tools they need to build and maintain successful security initiatives. He is an active Android security researcher/tinkerer, and has a keen interest in identifying security issues and trends on a large scale. Jack is a leader and founder of the OWASP Mobile Security Project. He is the lead developer for the OWASP GoatDroid project, and is the chairman of the OWASP Northern Virginia chapter.

'''June 2013'''

Topic: '''We see the future…and it isn’t pretty'''

Presented by: '''Andrea Mulligan, Sr. Director at Veracode'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, June 5, 6:30 pm

In this session Andrea presents research findings from the State of Software Security Report, which offers a before the breach look at security by examining the flaws commonly found in applications of all kinds. She will also examine what the research findings mean for security, predict how these flaws could cause history to repeat itself, and discuss how security pros can help change the future.

'''May 2013'''

Topic: '''Systems Thinking + Web Security'''

Presented by: '''Akamai'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, May 1, 6:30 pm

Akamai will present on ‘Systems Thinking + Web Security’. There will also be an audience review exercise facilitated by the Akamai presenters. This is a great chance to hear some interesting perspectives on web security from Akamai, who handles about one third of all internet traffic.

'''April 2013'''

Topic: '''Go Fast. Be Secure: Effectively Govern the Use of Open Source Components Throughout the SDLC'''

Presented by: '''Sonotype'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, April 3, 6:30 pm

* Open Source Software (OSS) Component supply chain complexities and realities. Open source is constantly changing and knowing the version in your software, as well as the current version history of the component (how do you show an auditor you are using a current version) is important.
* Open Source Consumption Patterns from the Central Repository. Which versions are the most popular can tell you which versions are the most stable, useful, secure etc.
* OWASP Top 10 (A9) - Using Components with Known Vulnerabilities. To decide on the risk of OSS components with vulnerabilities, you need to know the vulnerabilities, their severity and which components they occur in as well as where in the code dependency tree they are.
* OSS Security, Quality and License policies must be woven into the development process. Knowing the number and type of open source licenses in your software can be important to the legal standing of your code and if it conflicts with any corporate standards. The licensing is also important in order to know the restrictions on changing the software.
* OSS Component Policy Examples
* Example Application Compositions Reports
* Example Use cases IDE, CI, repository, production applications
* Discussion

About Sonatype:

Sonatype operates the Central Repository, the industry's primary source for open-source components, housing more than 400,000 components and serving more than five billion requests per year from more than 60,000 organizations. The company has been a pioneer in component-based software development since its founding by Jason van Zyl, the creator of the Apache Maven build management system and the Central Repository.

'''March 2013'''

Topic: '''What is BSIMM?'''

Speaker: '''Nabil Hannan'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Nabil is Director of Vulnerability Assessments and Managing Consultant at Cigital.

The purpose of the BSIMM is to quantify the activities carried out by real software security initiatives. BSIMM is a study of the secure development practices of over 50 organizations, analyzed along the dimensions that were found in the data, not along preconceived ideas of what secure development should be.

BSIMM describes the work of 974 software security group members working with a satellite of 2039 people to secure the software developed by 218,286 developers.

The BSIMM describes 111 activities that any organization can put into practice. The activities are described in twelve practices grouped into four domains. Associated with each activity is an objective.

'''February 2013'''

Topic: '''BroBot'''

Speaker: '''Eric Kobrin, Akamai'''

When: Wednesday, February 6, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Eric Kobrin is a Senior Security Architect in the Infosec organization of Akamai Technologies, the global leader in Cloud-based application acceleration and content delivery. Eric has been involved in Software Architecture for over 15 years, having worked at such companies and IBM, Velocitude and eDiets.com. He has a passion for programming languages, security, and software performance and has worked in all layers of the software stack from hypervisors to complex servers and web applications. Eric's works have been published, presented at international conferences and patented.

His presentation will provide an analysis of the BroBot DDOS attacks, including discussion of:

* Vulnerable system discovery
* Zombie compromise
* Control structure
* Attack traffic
* Mitigation steps

'''January 2013'''

Topic: '''Third-Party Application Analysis: Best Practices and Lessons Learned'''

Speaker: '''Chad Holmes, Veracode'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Chad Holmes will present details of the work Veracode has been doing with their 3rd Party program, discuss the technical and business challenges that have arisen during that time and lead a discussion on what team members can do to help drive adoption of security best practices across their vendor community.

The flow of the presentation is designed to drive discussion within an audience – both from a technical and business perspective with some anecdotal stories. Chad wants this to be an interactive discussion so he’ll have questions and you should bring yours I’ve already sent him some. The order of the presentation is:

· Adoption rates of externally developed software

· The risk within those apps

· Some deeper stats on what “3rd party” really means (total outsourcing/total COTS produced/open source/imported libraries/etc)

· Some raw data about our experiences (to show this is based on a large sample size rather than “Look how awesome Veracode is!”)

· Challenges that will be faced (business, intellectual property, policy, analysis capabilities, etc)

· Best Practices for high rates of adoption

· Lessons Learned and Recommendations

Chad Holmes has over 10 years of software development and application security experience. During his time at Veracode, Chad has lead the redesign and execution of the third-party analysis process to allow for a more streamlined approach while still addressing common ISV intellectual property concerns. In addition to his third-party analysis responsibilities, Chad's previous work as a Security Program Manager has lead to the successful roll out and improvement of multiple corporate application security groups.

'''June 2012'''
Location - Microsoft Waltham (201 Jones Rd., Sixth Floor Waltham, MA)

Speaker '''Will Vandevanter - Rapid 7'''

'''Fingerprinting web applications of all kinds'''

This turbo talk will introduce a new Metasploit module that fingerprints "known" web applications, attempts the default credentials for the application, and runs an associated exploit or authenticated access module if applicable. Some example fingerprints in the database target common enterprise web applications including Microsoft products (Outlook Web Access, Sharepoint), printers (Xerox Document Centre), security cameras, routers, and others.

Will Vandevanter is a senior penetration tester and researcher at Rapid7. His focus interests include web application security and secure code. He has previously spoken at Defcon, SOURCE, BSides LV, and other conferences.

'''May 31 2012'''

Location - Jobspring, Boston. 545 Boylston st.

Speaker - '''Glenn Gramling, Vice President, Cenzic'''

“Cloudy with a Chance of Hack”

Cloud computing is a cost effective and efficient way for enterprises to automate their processes. However organizations need to be aware of the pitfalls of the many cloud solutions out there - one of the main being security. Most cloud applications were built for ease of use and without security necessarily in mind. Companies need to be asking their solution providers about the security measures used in developing the application and get an independent verification to make sure there are no gaping holes. With over 75% of attacks occurring through the Web, any attack through these applications can lead to leakage of confidential information and embarrassment. In this session, we'll give attendees tips and tricks to prepare them for the potential of "stormy weather."

Glenn Gramling is responsible for global sales and business development for Cenzic’s application security.

'''April 11, 2012'''

Location - Microsoft Waltham (201 Jones Rd., Sixth Floor Waltham, MA)

Speaker - '''David Eoff, Senior Product Marketing Manager, HP Enterprise Security'''

David is a Senior Product Marketing Manager, within the Enterprise Security Products division of HP focused on Fortify application security. His 18+ years of background in software and hardware enterprise marketing provides a solid foundation for his marketing of the HP security solutions.

Prior to joining Fortify in 2009 and being acquired by HP, David ran Firewall and IPS marketing for the Security division of Nokia Corporation. In addition, he has held multiple positions in product marketing, product management, channel marketing and sales while working for Oracle, EMC, Legato, BMC Software and several start-ups.

Topic - '''Gray, the New Black: Gray-Box Vulnerability Testing'''

Over the years, two key techniques have emerged as the most effective for finding security vulnerabilities in software: Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST). While DAST and SAST each possess unique strengths, the “Holy Grail” of security testing is thought to be “hybrid” – a technique that combines and correlates the results from both testing methods, maximizing the advantages of each. Until recently, however, a critical element has been missing from first generation hybrid solutions: information about the inner workings and behavior of applications undergoing DAST and SAST analysis.

This presentation will introduce you to the next generation of hybrid security analysis – what it is, how it works, and the benefits it offers. It will also address (and dispel) the claims against hybrid, and leave you with a clear understanding of how the new generation of hybrid will enable organizations to resolve their most critical software security issues faster and more cost-effectively than any other available analysis technology.

'''March 8, 2012, with the Boston Security Meetup group'''

Location - [http://maps.google.com/maps?q=Jobspring+Partners,+Boylston+Street,+Boston,+MA&hl=en&sll=42.362243,-71.081628&sspn=0.019549,0.037594&oq=jobspring&t=v&hq=Jobspring+Partners,&hnear=Boylston+St,+Boston,+Massachusetts&z=17 JobSpring, Boylston St.]

Topic - '''Corporate Espionage for Dummies: The Hidden Threat of Embedded Web Servers'''

Speaker - VP for Security Research at ZScaler, along with other speakers at the security meetup.

Today, everything from kitchen appliances to television sets come with an IP address. Network connectivity for various hardware devices opens up exciting opportunities. Forgot to lower the thermostat before leaving the house? Simply access it online. Need to record a show? Start the DVR with a mobile app. While embedded web servers are now as common as digital displays in hardware devices, sadly, security is not. What if that same convenience exposed photocopied documents online or allowed outsiders to record your telephone conversations? A frightening thought indeed.

Software vendors have been forced to climb the security learning curve. As independent researchers uncovered embarrassing vulnerabilities, vendors had little choice but to plug the holes and revamp development lifecycles to bake security into products. Vendors of embedded web servers have faced minimal scrutiny and as such are at least a decade behind when it comes to security practices. Today, network connected devices are regularly deployed with virtually no security whatsoever.

The risk of insecure embedded web servers has been amplified by insecure networking practices. Every home and small business now runs a wireless network, but it was likely set up by someone with virtually no networking expertise. As such, many devices designed only for LAN access are now unintentionally Internet facing and wide open to attack from anyone, regardless of their location.

Leveraging the power of cloud based services, Zscaler spent several months scanning large portions of the Internet to understand the scope of this threat. Our findings will make any business owner think twice before purchasing a 'wifi enabled' device. We'll share the results of our findings, reveal specific vulnerabilities in a multitude of appliances and discuss how embedded web servers will represent a target rich environment for years to come.

'''December 13, 2011, 6:30, Microsoft NERD, Cambridge, Horace Mann Room'''

'''Jeremiah Grossman – Founder and CTO WhiteHat Security'''

Directions: http://microsoftcambridge.com/About/Directions/tabid/89/Default.aspx

'''September 14 2011'''

'''Dinis Cruz - OWASP O2 Platform'''

The O2 Platform is focused on automating application security knowledge and workflows. It is a library of scriptable objects specifically designed for developers and security consultants to be able to perform quick, effective and thorough source code-driven application security reviews (blackbox + whitebox).

'''September 7 2011'''

'''Adriel Desautels – Differences between Penetration Testing and Vulnerability Scanning'''

'''July 2011'''

'''Anurag Agarwal, the founder of MyAppSecurity'''

'''Session 1 - Managing Risk with Threat Modeling'''
Threat Modeling can help by guiding the Application Development Teams to ensure your Security Policies get properly coded into the Applications at time of Development. By creating pre-approved methods of coding for your development teams, and applying them in a repeatable and scalable process, you can assist your development teams in building a secure application easily and effortlessly.

'''Session 2 - False Positive, False Negative and False Sense of Security'''
This interactive session will talk about the pros and cons of using black box testing tools and discuss their effectiveness in building a mature software security program.

'''Thursday June 2'''

Location - '''Microsoft NERD''' - http://microsoftcambridge.com/About/Directions/tabid/89/Default.aspx

'''Topic - Bringing Sexy Back: Defensive Measures That Actually Work'''

Presenter - Paul Asadoorian, Founder & CEO, PaulDotCom Enterprises

There is a plethora of information available on how to break into systems, steal information, and compromise users. As a penetration tester, I have performed testing on a regular basis that reveals severe security weaknesses in several organizations, and many of my peers have reported on the same. However, once you "own" the network and report on how you accomplished your goals, now what? Sure, we make defensive recommendations, but consistently it has been proven that security can be bypassed. Not enough focus is given to what works defensively. We have a lot of technology at our disposal: firewalls, intrusion detection, log correlation, but it provides little protection from today's threats and is often not implemented effectively. This talk will focus on taking an offensive look at defense. Applying techniques that are simple, yet break the mold of traditional defensive measures. We will explore setting up "traps" for attackers, slowing them down with simple scripts, using honeypots, planting bugs, and most importantly tying these methods to "enterprise security". This talk will also include real-world examples of the techniques in action from a live, heavily attacked site. Topics will include:

*Using wireless “attacks” on the attackers
*Implementing the Metasploit Decloak engine to find the attackers
*Setting traps to detect web application attacks
*Integrating results into your enterprise log management tool

The goal of this talk is to make defense “sexy”…

'''Presenter Bio'''

Paul Asadoorian is currently the "Product Evangelist" for Tenable Network Security, where he showcases vulnerability scanning and management through blogs, podcasts and videos. Paul is also the founder of PaulDotCom, an organization centered around the award winning "PaulDotCom Security Weekly" podcast that brings listeners the latest in security news, vulnerabilities, research and interviews with the security industry's finest. Paul has a background in penetration testing, intrusion detection, and is the co-author of "WRT54G Ultimate Hacking", a book dedicated to hacking Linksys routers.

'''Thursday May 26'''

Location - Microsoft Waltham (201 Jones Rd., Sixth Floor Waltham, MA)

'''Topic - OWASP Top 10 issue #4 – Insecure Direct Object Reference'''

Presenter - Jim Weiler, Sr. Mgr. Information Security, Starwood Hotels and President of OWASP Boston

Jim Weiler will discuss threat models, risks and various remediations of issue #4 in the 2010 OWASP Top 10 – Insecure Direct Object References.

'''Topic - A Web-Application Architecture for Regulatory Compliant Cloud Computing'''

Presenter - Arshad Noor, StrongAuth

The emergence of cloud-computing as an alternative deployment strategy for IT systems presents many opportunities, yet challenges traditional notions of data-security. The fact that data-security regulations are developing teeth, leaves information technology professionals perplexed on how to take advantage of cloud-computing while proving compliance to regulations for protecting sensitive information.

This presentation presents an architecture for building the next generation of web-applications. This architecture allows you to leverage emerging technologies such as cloud-computing, cloud-storage and enterprise key-management (EKM) to derive benefits such as lower costs, faster time-to-market and immense scalability with smaller investments - while proving compliance to PCI-DSS, HIPAA/HITECH and similar data-security regulations.

'''Presenter Bio'''

Arshad Noor is the CTO of StrongAuth, Inc, a Silicon Vally-based company that specializes in enterprise key management. He is the designer and lead-developer of StrongKey, the industry's first open-source Symmetric Key Management System, and the KeyAppliance - the industry's first appliance combining encryption, tokenization, key-management and a cryptographic hardware module at an unprecedented value. He has written many papers and spoken at many forums on the subject of encryption and key-management over the years.

''' CANCELLED '''

'''Topic – Secure Application design and Coding''' -- CANCELLED

Presenter - Josh Abraham, Rapid 7

'''Speaker Bio '''

'''April 2011'''

Ed Adams Security Innovation -- the new OWASP Exams Project and the work being done by the OWASP Academies Working Group

<br>

'''March 2011'''

Josh Abraham, Rapid 7

Owning the world, one mobile app at a time, and web services pen testing.

<br>

'''Febrary 2011'''

Rob Cheyne, CEO of Safelight Security -

Security Leadership series: Delivering a successful security presentation

<br>

'''December 2010'''

Application Architecture Security Assessment - Second session

Rob Cheyne, CEO SafeLight Security Advisors

<br>

'''November 2010'''

Open SAMM – Software Assurance Maturity Model

Shakeel Tufail is the Federal Practice Manager at Fortify, an HP company.

<br>

'''October 2010'''

Rob Cheyne, CEO SafeLight Security Advisors Overview: In this highly interactive two-part workshop, Rob Cheyne of Safelight Security will show you the basics of conducting a real-world architecture & design review. This workshop draws from Safelight's Security Architecture Fundamentals training course, a two-day course frequently used to teach Fortune 500 companies how to look at their system architectures from both the hacker's and the designer’s point of view.

'''July 2010'''

Lightning Talk – Rob Cheyne, CEO Safelight Security Advisors In this installment of the Safelight lightning talks series, Rob will present the basics of a Cross-site Request Forgery (CSRF).

Main Presentation - Drive-by Pharming with MonkeyFist

Joey Peloquin - Director of Application Security, Fishnet Security

'''June 2010'''

Rob Cheyne Lightning Talk - topic to be announced

Main Presentation - Ryan Barnett The Web Hacking Incident Database (WHID) is a Web Application Security Consortium project dedicated to maintaining a list of web applications related security incidents. Ryan Barnett is director of application security research at Breach Security where he leads Breach Security Labs.

'''May 2010'''

Rob Cheyne Lightning Talk - SQL Injection

Vinnie Liu - Data Exposure, New Approaches to Open Source Intelligence Techniques, and Incident Handling

<br>

'''April 2010'''

Dan Hestad Security Innovation Dan will be talking about his experiences with PCI and web applications, and answering questions about do's and don'ts of acceptable PCI practices in web applications.

'''March 2010'''

Zack Lanier - Disclosure Samsara, or "the endless vulnerability disclosure debate"

http://n0where.org/talks/samsara_20100310.html

http://n0where.org/talks/samsara_20100310.pdf (very large PDF)

<br>

'''February 2010'''

Rob Cheyne of Safelight Security Advisors; New Technology, Same Old Vulnerabilities

<br>

'''January 2010 at Microsoft NERD, Cambridge'''

Josh Abraham, Rapid 7 Technologies

'''December 2009'''

Eric Bender, Cenzic

'''November 2009'''

Jim Weiler, Sr. Mgr. Information Security, Starwood Hotels - Web Application Vulnerability Scanners

Mush Hakhinian, Leader, Application Security Practice, IntraLinks - Secure coding with no money down using SONAR: unleashing the power of open-source code analysis tools

<br>

'''October 2009'''

Paul Schofield, Senior Security Engineer, Imperva - From Rivals to BFF: WAF & VA Unite

<br>

'''September 2009 at CORE Technologies, Boston'''

Paul Asadoorian, Pauldotcom.com

Alex Horan, CORE Security

<br>

'''May 2009'''

Joey Peloquin, Fishnet Security, Secure SDLC: The Good, the Bad and the Ugly [http://www.owasp.org/images/4/48/SecureSDLC-GoodBadUgly.pdf presentation pdf]

<br>

'''March 2009'''

Sabha Kazerooni, Security Compass - Exploit Me tools; Framework Level Threat Analysis

[http://www.owasp.org/images/5/5a/Security_Compass_Exploilt_Me.pdf ExploitMe Document]

[http://www.owasp.org/images/e/ef/Security_Compass_Framework-level_Threat_Analysis.pdf Framework Level Threat Analysis document]

Meeting Pizza Sponsor - Arcot

Arcot is a leader in online fraud prevention, strong authentication and eDocument security. Arcot's solutions are easily deployed, low-cost and extremely scalable, allowing organizations to transparently protect their users from fraud without changing user behavior or requiring expensive hardware.

Arcot can be contacted thru Michael Kreppein, michael.kreppein@arcot.com, 617-467-5200

'''December 2008'''

Brian Holyfield, Gothem Digital Science

Tamper Proofing Web Applications http://www.gdssecurity.com/l/b/2008/12/04/

'''June 2008'''

Jeremiah Grossman; Founder and CTO, Whitehat Security

Appetizer - Hacking Intranets from the Outside (Just when you thought your network was safe) Port scanning with JavaScript

Main Topic - Business Logic Flaws: How they put your Websites at Risk

'''March 2008'''

Chris Eng; Senior Director, Security Research, Veracode

Description – Attacking crypto in web applications

'''December 2007'''

Scott Matsumoto; Principal Consultant, Cigital

Description – You Say Tomayto and I Say Tomahto – Talking to Developers about Application Security

[https://www.owasp.org/images/5/5b/BostonOWASP200712-Cigital.pdf Cigital Presentation]

'''November 2007'''

Tom Mulvehill Ounce Labs

Description – Tom will share his knowledge and expertise on implementing security into the software development life cycle. This presentation will cover how to bring practicality into secure software development. Several integration models will be explored as well as solutions for potential obstacles

[https://www.owasp.org/images/f/f8/Ounce_OWASP_07NOV07ppt.zip Ounce presentation]

<br>

'''October 2007'''

George Johnson, Principal Software Engineer EMC; CISSP

An Introduction to Threat Modeling.

<br>

'''September 2007'''

Day of Worldwide OWASP 1 day conferences on the topic "Privacy in the 21st Century"

'''June 2007'''

Tool Talk - Jim Weiler - WebGoat and Crosssite Request Forgeries

Danny Allan; Director, Security Research, Watchfire

Topic: Exploitation of the OWASP Top 10: Attacks and Strategies

'''March 2007'''

Jeremiah Grossman, CTO Whitehat Security: Top 10 Web Application Hacks of 2006

<br>

'''January 2007'''

Dave Low, RSA the Security Division of EMC: encryption case studies

<br>

'''November 2006'''

<br>

'''September 2006'''

Mike Gavin, Forrester Research: Web Application Firewalls

<br>

'''June 2006'''

Imperva - Application and Database Vulnerabilities and Intrusion Prevention

Jim Weiler - Using Paros Proxy Server as a Web Application Vulnerability tool

<br>

'''May 2006'''

<br>

'''April 2006'''

Dennis Hurst; SPI Dynamics: A study of AJAX Hacking

Jim Weiler; OWASP Boston: Using Paros HTTP proxy, part 1. first meeting with all demos, no powerpoints!

<br>

'''March 2006'''

Mateo Meucci; OWASP Italy [http://www.owasp.org/images/8/8c/Anatomy_of_2_Web_App_Testing.zip Anatomy of 2 web attacks]

Tom Stracener; Cenzic Web Application Vulnerabilities

<br>

'''February 2006'''

Ron Ben Natan; Guardium CTO Database Security: Protecting Identity Information at the Source

<br>

'''January 2006'''

David Low, Senior Field Engineer: RSA Practical Encryption

<br>

'''December 2005'''

Paul Galwas, Product Manager: nCipher [http://www.owasp.org/docroot/owasp/misc/OWASP051207.ppt Enigma variations: Key Management controlled]

<br>

'''November 2005'''

Robert Hurlbut, Independent Consultant [http://www.owasp.org/docroot/owasp/misc/OWASP_Hurlbut_ThreatModelingforWebApplicaitons.zip Threat Modeling for web applications]

<br>

'''October 2005'''

Prateek Mishra, Ph.D. Director, Security Standards and Strategy: Oracle Corp Chaiman of the OASIS Security Services (SAML) Technical Committee - [http://www.owasp.org/docroot/owasp/misc/Federation-Introduction-Overview-01.ppt Identity Federation : Prospects and Challenges]

Ryan Shorter, Sr. System Engineer: Netcontinuum - Application Security Gateways

<br>

'''September 2005'''

Dr. Herbert Thompson, Chief Security Strategist: SecurityInnovation - How to Break Software Security

<br>

'''July 2005'''

Mark O'Neill, CTO: Vordel - [http://www.owasp.org/docroot/owasp/misc/MarkOneill.pdf Giving SOAP a REST? A look at the intersection of Web Application Security and Web Services Security]

'''June 2005'''

Arian Evans, National Practice Lead, Senior Security Engineer: Fishnet Security [http://www.owasp.org/conferences/appsec2005dc/schedule.html Overview of Application Security Tools]

<br>

'''May 2005'''

Patrick Hynds, CTO: Critical Sites - [http://www.owasp.org/docroot/owasp/misc/Passwords-Keys_to_the_Kingdom_Dev_V1.ppt Passwords - Keys to the Kingdom]

<br>

'''April 2005'''

Jonathan Levin - [http://www.owasp.org/docroot/owasp/misc/JLevinRandoms.pdf Of Random Numbers]

Jothy Rosenberg, Founder and CTO: Service Integrity - [http://www.owasp.org/docroot/owasp/misc/JothyRWebSvcsSec.ppt Web Services Security]

<br>

'''March 2005'''

Joe Stagner: Microsoft Let's talk about Application Security

<br>

'''Feb 2005'''

Application Security Inc. PowerPoint slides for the [http://www.owasp.org/docroot/owasp/misc/Anatomy+of+an+Attack.ppt Anatomy of a Database Attack.]

== Local Chapter Information ==

To find out more about the Boston chapter, just join the [http://lists.owasp.org/mailman/listinfo/owasp-boston OWASP Boston mailing list].

The chapter shipping/mailing address is:

OWASP Boston <br />
35 Wachusett Dr <br />
Lexington, MA 02421

== Links ==

[http://www.owasp.org/index.php/Reviews_of_security_podcasts Reviews of security podcasts]

[https://www.owasp.org/index.php/2017_BASC_Homepage Boston Application Security Conference 2017]

[[2016 BASC Homepage|Boston Application Security Conference 2016]]

[[2015 BASC Homepage|Boston Application Security Conference 2015]]

[[2014 BASC Homepage|Boston Application Security Conference 2014]]

[[2013 BASC Homepage|Boston Application Security Conference 2013]]

[[2012 BASC Homepage|Boston Application Security Conference 2012]]

[[2011 BASC Homepage|Boston Application Security Conference 2011]]

[[2010 BASC Homepage|Boston Application Security Conference 2010]]

== Boston OWASP Chapter Leaders ==

'''Contact'''

* Email the [mailto:boston-leaders@owasp.org chapter leaders].

'''President'''

* [mailto:jim.weiler@owasp.org Jim Weiler] 781 356 0067

'''Board of Directors'''

* [mailto:lindaleigh.aberdale@owasp.org LindaLeigh Aberdale]
* [mailto:mark.arnold@owasp.org Mark Arnold]
* [mailto:tom.conner@owasp.org Tom Conner]
* [mailto:mike.perez@owasp.org Mike Perez]
* [mailto:roy.wattanasin@owasp.org Roy Wattanasin]
* [mailto:pedro.marcano@owasp.org Pedro Marcano]
* [mailto:Mark.Schlepphorst@owasp.org Mark Schlepphorst]
* [mailto:Ori.Zigindere@owasp.org Ori Zigindere]
__NOTOC__

[[Category:Boston]]
[[Category:OWASP_Chapter]]
[[Category:Massachusetts]]

Boston

2019-05-04T03:27:43Z

Jweiler: /* Chapter Meetings --- Our Fifteenth Year */

{{Chapter Template|chaptername=Boston|extra=Follow @OWASPBOSTON on Twitter. The chapter leader is [mailto:boston@owasp.org Jim Weiler]. The Boston chapter is grateful for support from Constant Contact, Salesforce, Microsoft and Akamai for generously hosting space and their hospitality for various events.

__FORCETOC__

The Chapter would also like to thank our sponsors for their generous support.|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Boston|emailarchives=http://lists.owasp.org/pipermail/owasp-Boston}}

== Chapter Sponsor ==
[[File:SIlogostacked.png|Security Innovation|https://www.securityinnovation.com/]]

[[File:Veracode logo.png|Veracode|https://www.veracode.com/]]

== Boston Application Security Conference ==

[[Image:Boston-Banner-468x60.gif|link=2018_BASC_Homepage]] [[Image:twitter_32.png|link=https://twitter.com/@BASConf]] BASC 2019, the Boston Application Security Conference will take place 8:30am to 6:30pm on Saturday, October 19th at Microsoft, 5 Wayside Road, Burlington, MA. [[2018 BASC Homepage|Read more]]

== Chapter Meetings --- Our Fifteenth Year ==

We now use [http://www.meetup.com/owaspboston/ meetup] to organize meetings.

We meet whenever a speaker and a venue have available dates, 6:30 to 9 pm.

Everyone is welcome to come to any meeting, there is no signup or joining criteria, just come if it sounds interesting. You can join the OWASP Boston Google group. This list is very low volume (2 - 3 emails/month); it is used to remind people about each monthly meeting, inform about local application security events and special chapter offers.


Upcoming Meetings

CMD+CTRL Web Application Hacking Cyber Range May 22, 2019 @ 6:00-9:00pm Athena Health Watertown

Want to test your skills in identifying web app vulnerabilities? Join OWASP Boston, Athena Health and Security Innovation as members compete in CMD+CTRL, a web application cyber range where players exploit their way through hundreds of vulnerabilities that lurk in business applications today. Success means learning quickly that attack and defense is all about thinking on your feet. Standard capture the flag using network and operating attack skills will not be much use here; understanding the OWASP Top 10 risks will help you find the vulnerabilities.

For each vulnerability you uncover, you are awarded points. Climb the interactive leaderboard for a chance to win prizes! CMD+CTRL is ideal for development teams to train and develop skills, but anyone involved in keeping your organization’s data secure can play - from developers and managers and even CISOs.

YOU CAN ONLY REGISTER ON THE SECURITY INNOVATION REGISTRATION SITE AT THIS LINK - <nowiki>https://web.securityinnovation.com/athenahealth2019</nowiki>

Register early to reserve your spot !

Just bring a laptop. Pizza and soda will be provided.

Venue/Location of the event:

Athena Health

311 Arsenal St.

Watertown, MA 02472

See the attached map -

Park in only P2 visitor lot or in garages P1 and P3. Parking is free.

The main lobby door is at “S1” shuttle pickup icon.

Enter the lobby and sign in at the front desk to pick up credentials.

Directions to the event room will be provided at that time

=== Upcoming Training ===
TBD

=== Past Meetings ===

''January 29th, 2019'' - Cambridge [https://web.securityinnovation.com/owaspboston2019 Partnered with Security Innovation]

Location: [https://goo.gl/maps/w11GUuJJAbo Quick Base office]

5PM- '''Just bring your computer and evil inner-doer and you are ready to roll!'''

Security Innovation is teaming up with OWASP Boston to offer attendees a fun "find the vulnerabilities" game - CMD+CTRL Cyber Range - that shows how hackers break into websites and teaches the importance of secure coding habits.

The CMD+CTRL Cyber Range we will be using is called ShadowBank, a banking website where players compete to find vulnerabilities, score points, and move up the leaderboard. Leveraging cheat sheets, attack tables, and expert led training sessions, platers take their shot at stealing money, manipulating share prices, and conducting other nefarious acts.

''June 14th, 2017'' - Burlington [https://www.meetup.com/owaspboston/events/240033562/ Meetup]

Location: [https://maps.google.com/maps?f=q&hl=en&q=5+Wall+St.%2C+Burlington%2C+MA%2C+us SalesForce (was Demandware) 5 Wall St., Burlington, MA]

Everyone should report to Akamai 90 Broadway in the lobby and indicate about the Meetup. Someone form the staff will escort them to the 12th floor.

5:30 - 6:15 - '''Chat, Chew and Brew'''

6:15 - 6:45 '''News, Announcements'''

Chapter and OWASP events and news, audience announcements, questions, application security news(Google and Symantec certs, HTML5, Chrome features, SDLC and Microservices, others?)

7:00 pm ''' Is RASP Ready?'''

Runtime Application Self-Protection is overhyped, according to many analysts and pundits. RASP promises applications that protect themselves - which sounds impossible - how can an application possibly protect itself? An agent that sits inside the app sounds like a deployment nightmare at worst, and a drain on the app at best. What’s the reality? Where are we now and what have we learned?

We’ve seen deployment successes and failures, and we will draw from those specific experiences to describe:
Where does RASP work?
* What applications are well-suited for RASP?
* What types (organizational structure, culture, or skillset) of organizations are well-suited for RASP?

What is the reality of RASP?
* Is RASP a deployment model or a feature set?
* How mature is RASP? Is it an over-hyped immature space, enterprise-ready, or somewhere in between?
* Which RASP capabilities do organizations use? And how do they validate those capabilities in their own environments?
* Can RASP replace the WAF?

We will conclude, not with a sales pitch, but some lessons learned on: the three must have attributes for RASP, some suggestions on good candidates for RASP – both types of teams and types of applications, and finally - if, how, and when to get started.

''Speaker'': Michael Feiertag, CEO and Co-Founder, tCell
Before co-founding tCell at the end of 2014, Michael led a string of successful products – most recently as head of products at Okta, and prior to that, as technology director at Blue Coat. Prior to Blue Coat, Michael held product management, engineering, and sales positions at several start-ups. Michael holds a B.S. from The University of Chicago, and an M.S. from the University of Maryland

'''May 2, 2017''' - Burlington [https://www.meetup.com/owaspboston/events/239130768/ Meetup]

Location: [https://maps.google.com/maps?f=q&hl=en&q=5+Wall+St.%2C+Burlington%2C+MA%2C+us SalesForce (was Demandware) 5 Wall St., Burlington, MA]

Everyone should report to Akamai 90 Broadway in the lobby and indicate about the Meetup. Someone form the staff will escort them to the 12th floor.

5:30 - 6:15 - '''Chat, Chew and Brew'''

6:15 - 6:45 '''News, Announcements'''

Chapter and OWASP events and news, audience announcements, questions, application security news(Google and Symantec certs, HTML5, Chrome features, SDLC and Microservices, others?)

6:50 pm '''Random Number Generation - Lava Lamps, Clouds, New Standards and the IoT - Richard Moulds'''

The SANS Institute recently listed "Weak random number generators" as one of the 7 most dangerous security techniques to watch in 2017. But how do you really know how good your random numbers are? Virtualization and IoT make things worse and new standards are a wake-up call. Random numbers are the basis of security for all cryptography, yet they are often taken for granted. Without entropy, crypto is just math.

Learn why random numbers are so hard to generate and validate, compare different technologies in use today across virtualized environments, and discuss operational steps to take the risk out of random numbers and help secure cryptosystems even into the era of quantum computers.

''Speaker'': Richard Moulds, General Manager of Whitewood Security, has spoken at RSA 2017 and at several OWASP chapter events in New York, Chicago and Austin. Richard has over 20 years of experience in the area of cryptography and encryption.

'''November 2, 2016''' - Cambridge [https://www.meetup.com/owaspboston/events/234648485/ Meetup]

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 90 Broadway, Cambridge, MA 02142 (down the street from the usual location)

Everyone should report to Akamai 90 Broadway in the lobby and indicate about the Meetup. Someone form the staff will escort them to the 12th floor.

6:30 '''News, Announcements'''

7:00 '<nowiki/>''Advanced Persistent Legal Threats''' - '''''<nowiki/>'''William Gamble, JD, LLM, EMBA'''

Abstract: Good cyber security can protect IT infrastructure against many attacks. Because of the difficulty in monetizing cyber thefts, the direct loss of a breach can be limited. However, the legal costs, both from government agencies and plaintiffs, can be far greater. The legal landscape, both in the US and internationally is changing as fast if not faster than the technology.

Bio: I am a lawyer and a member of the Florida Bar.I used to practice tax, securities and banking law. I have written three books and spoken around the world on the economic efficiency of legal and regulatory infrastructures specifically in emerging markets like China. Over the past two years, I have immersed myself in cyber security. I now hold the CompTIA A+, Network+, and Security+. I will take the CASP next month. Besides keeping up with the regulations, I am studying incident response and auditing. I am also working toward my health care law certification. My hero is Dr. Johannes Ullrich.

'''September 28, 2016''' - Burlington - [http://www.meetup.com/owaspboston/events/233921522/ Meetup]

Location: [https://www.google.com/maps/place/5+Wall+St,+Burlington,+MA+01803/@42.4877956,-71.1904085,17z/data=!3m1!4b1!4m5!3m4!1s0x89e3758106c4cb55:0xc155e97a6d34883e!8m2!3d42.4877956!4d-71.1882198?hl=en Demandware] at 5 Wall St., Burlington, MA

6:00 '''News, Announcements'''

6:15 '''OWASP Top 10 #1 - Injection Flaws'''

Jim Weiler will discuss XML External Entity Injection flaws; how it works, how to prevent, code examples.

6:45 '<nowiki/>''From the Frontlines of RASP Adoption''' - '''''<nowiki/>'''Goran Begic, VP of Product, IMMUNIO'''

Runtime Application Self-Protection (RASP) is one of the newest technologies coined by Gartner and it is in early stages of adoption in the industry. It promises dynamic defense and automatic mitigation of vulnerabilities in web applications.

This presentation is a summary of experiences from several dozens of commercial evaluations and early adoptions in production that took place this year and provides some examples of situations and challenges that are not specific to any individual vendor. In this talk Goran will provide an overview of buying criteria and evaluation requirements across different industries and some typical pitfalls that can slow down adoption.

After the introduction and a brief reminder on the technology Goran will invite audience to participate in discussion about organizational requirements for adoption and operationalization of RASP.

Questions for discussion:

My application is under attack.
*What actions should I take?
*Who owns the response?
*Which attacks should I respond to and which ones can I ignore?
*How to get started with mitigation provided by technology?
*Does RASP fit with DevOps?
*Does RASP help with remediation?

What this presentation is not: This is not a product pitch in any way. Evaluation criteria, comparison of RASP with IAST and other security technologies, personal experiences and examples discussed in this talk are generally applicable to all RASP solutions.

Key takeaways:

At the end of the presentation you will:
*get a better understanding of requirements for evaluation of RASP and its use cases,
*if you can pull a successful evaluation alone, or if you will need participation of other groups / teams
*learn about critical criteria for success of RASP in production
*how this criteria different relative to appsec testing tools.

'''September 7, 2016''' - Cambridge - [http://www.meetup.com/owaspboston/events/229223967/ Meetup]

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 150 Broadway, Cambridge, MA 02142 (aka 8 Cambridge Center)

6:30 '''News, OWASP tools, documents review'''

7:00 '''Docker Containers and Application Security''' - '''Tsvi Korren'''

Docker containers are transforming the way applications are developed and deployed. Closely tied to DevOps and Continuous Delivery, containers introduce both risks and opportunities to security management in Web applications. This talk will introduce the basic concepts of containers, how companies use them today and how to support this technology while elevating the security posture of your application stacks.

Tsvi Korren, CISSP, has been an enterprise IT professional for 20 years with background in business process consulting in large organizations. Most recently at CA Technologies, he worked across verticals in government, retail, financial institutions and healthcare to implement compliance and security processes, from Identity and Access to Host and Server Controls. Tsvi is currently the director of technical services at Aqua, concentrating on building bridges between DevOps and Security.

'''June 8, 2016''' - Burlington - [http://www.meetup.com/owaspboston/events/230842887/ Meetup]

Location: [https://www.google.com/maps/place/5+Wall+St,+Burlington,+MA+01803/@42.4877956,-71.1904085,17z/data=!3m1!4b1!4m5!3m4!1s0x89e3758106c4cb55:0xc155e97a6d34883e!8m2!3d42.4877956!4d-71.1882198?hl=en Demandware] at 5 Wall St., Burlington, MA

6-6:30 '''News, announcements, job postings, etc. '''

6:30-7 '''Introduction to SQL Injection - Jim Weiler'''

7:00 '''Computer Science Curricula’s Failure - What Should We Do Now?''' - '''Ming Chow & Roy Wattanasin'''

We are still facing the same security vulnerabilities from over a decade ago. The problems are not going away anytime soon and a reason is because Computer Science curricula are still churning out students who are not even exposed to security. This talk will address the lack of emphasis on information security in Computer Science curricula, how CS curricula have an obligation, how to gradually fix the problem by integrating security into many Computer Science undergraduate and graduate classes, and success stories from students. This talk will also discuss what Tufts and Brandeis are currently working on to further address the security education problem by creating a joint cyber security and policy program that spans multiple departments. Additional points and feedback from the audience are encouraged to help with the issue. All are encourage to attend to submit your feedback to help!

Presenters:

Ming Chow - @0xmchow

Ming Chow is a Senior Lecturer at the Tufts University Department of Computer Science. His areas of work are in web and mobile engineering and web security. He was a web application developer for ten years at Harvard University. Ming has spoken at numerous organizations and conferences including the High Technology Crime Investigation Association - New England Chapter (HTCIA-NE), the Massachusetts Office of the Attorney General (AGO), John Hancock, OWASP, InfoSec World, DEF CON, Intel, SOURCE Conference, and BSides Boston. He was a mentor for a Proving Ground speaker at BSides Las Vegas in 2014 and 2015.

Roy Wattanasin - @wr0

Roy Wattanasin is an adjunct faculty at Brandeis University in both the Health and Medical Informatics and Information Security graduate programs. He spends most of his time leading, teaching and developing information security programs, finding vulnerabilities, performing incident response and working on many projects. Roy has spoken at many conferences including RSA, ISSA International, Source Conference, Braintank, Cyber Security World, OWASP and the Security BSides conferences. He is also a healthcare information security professional. He was a mentor for a Proving Ground speaker at BSides Las Vegas in 2015.

'''May 4, 2016''' - Cambridge - [http://www.meetup.com/owaspboston/events/229788205/ Meetup]

Location: Slightly different [http://www.akamai.com/html/about/locations.html Akamai] location: 90 Broadway, Cambridge, MA 02142 between Meadhall and the Mariott

6:30 '''News, OWASP tools, documents review'''

7:00 '''The ABCs of Source-Assisted Web Application Penetration Testing With OWASP ZAP''' - '''Dan Cornell'''

There are a number of reasons to use source code to assist in web application penetration testing such as making better use of penetration testers’ time, providing penetration testers with deeper insight into system behavior, and highlighting specific sections of so development teams can remediate vulnerabilities faster. Examples of these are provided using the open source ThreadFix plugin for the OWASP ZAP proxy and dynamic application security testing tool. These show opportunities attendees have to enhance their own penetration tests given access to source code.

This presentation covers the “ABCs” of source code assisted web application penetration testing: covering issues of attack surface enumeration, backdoor identification, and configuration issue discovery. Having access to the source lets an attacker enumerate all of the URLs and parameters an application exposes – essentially its attack surface. Knowing these allows pen testers greater application coverage during testing. In addition, access to source code can help to identify potential backdoors that have been intentionally added to the system. Comparing the results of blind spidering to a full attack surface model can identify items of interest such as hidden admin consoles or secret backdoor parameters. Finally, the presentation examines how access to source code can help identify configuration settings that may have an adverse impact on the security of the deployed application.

Dan Cornell is a globally recognized application security expert, Dan Cornell holds over 15 years of experience architecting, developing and securing web-based software systems. As the Chief Technology Officer and a Principal at Denim Group, Ltd., he leads the technology team to help Fortune 500 companies and government organizations integrate security throughout the development process. He is also the original creator of ThreadFix, Denim Group's industry leading application security program management platform. Cornell was Principal Investigator as Denim Group researched and developed the Hybrid Analysis Mapping (HAM) technology that lies at the heart of ThreadFix, through a Small Business Innovation Research (SBIR) contract with the Department of Homeland Security's Science and Technology Directorate.

More information at: http://www.denimgroup.com/about_team_dan.html

'''April 6, 2016''' - Cambridge - [http://www.meetup.com/owaspboston/events/229223967/ Meetup]

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 150 Broadway, Cambridge, MA 02142 (aka 8 Cambridge Center)

6:30 '''News, OWASP tools, documents review'''

7:00 '''Runtime Application Self-Protection (RASP) Tools''' - '''Kunal Anand'''

This talk will highlight the latest in AppSec and dive into a different kind of solution called Runtime Application Self-Protection (RASP). We'll also explore a new methodology called language theoretic security (LANGSEC) and explain how it can outperform existing approaches like pattern matching, regular expressions, etc. This talk will lay the foundation via informal and formal theory how lexers, tokenizers and parsers work. We’ll move onto constructing an open source toolchain to analyzing data and exploring interactive data visualizations. Along the way, we’ll cover performance tradeoffs and discuss the challenges of modern application security.

Kunal Anand is the co-founder and CTO of Prevoty, a runtime application security platform. Prior to that, he was the Director of Technology at the BBC Worldwide, overseeing engineering and operations across the company’s global Digital Entertainment and Gaming initiatives. Kunal also has several years of experience leading security, data and engineering at Gravity, MySpace and NASA’s JetPropulsion Laboratory. His work has been featured in Wired Magazine and Fast Company. Kunal received a B.S. from Babson College.

=== Past Training ===

'''March 16, 2016''' - Burlington - [http://www.meetup.com/owaspboston/events/229156529/ Meetup]

Location: Demandware, Burlington.

6:00 '''News, OWASP tools, documents review'''

6:30 '''Software Security by the Numbers''' - '''Chris Eng'''

Deep dive into data we’ve collected about the state of software security in 2016
* Based on scans of 200,000+ applications over an 18-month period
* How different industries and programming languages compare to one another
* Vulnerability remediation habits and patterns
* Three characteristics of a successful AppSec program

Chris Eng is vice president of research at Veracode. In this role, he leads the team responsible for integrating security expertise into all aspects of Veracode’s technology. Throughout his career, he has led projects breaking, building, and defending web applications and commercial software for some of the world’s largest companies. Chris is a frequent speaker at premier industry conferences, where he has presented on a diverse range of topics, including cryptographic attacks, agile security, mobile application security, and security metrics. He has been interviewed by Bloomberg, Fox Business, CBS, and other media outlets worldwide.

'''January 26, 2016''' - Waltham - [http://www.meetup.com/owaspboston/events/228202040/ Meetup]

Location: Constant Contact, Waltham. Trapelo Rd. exit from Rt. 128, toward Lincoln. The parking lot entrance is on the right, at the first traffic light. Drive around to the front of the office complex, facing the highway. Enter under the clock tower. Park in the front of the building and enter in the main building lobby, continue down the hallway and you will see the innovation center, enter in the large glass doors.

7:00 '''News, OWASP tools, documents review'''

7:20 '''What Security Testing Tools Miss'''

Black Duck Software presents - Static analysis, dynamic analysis, and other testing tools are all essential weapons against adversaries. But for the 80%+ of companies worldwide that use open source software in their application development these tools are ineffective in identifying and mitigating open source security risks . This presentation will cover:

The value of static and dynamic tools, and where they best fit in the Secure Development Lifecycle

Why these tools are not useful in identifying known vulnerabilities in open source components

Controls development and security professionals can deploy to select, detect, manage and monitor open source for existing and newly disclosed vulnerabilities

Food will be provided by Constant Contact.

'''November 2015''' - Cambridge - [http://www.meetup.com/owaspboston/events/226394218/ Meetup]

When: Wednesday, November 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 150 Broadway
Cambridge, MA 02142 (aka 8 Cambridge Center)

6:30 '''News, views, announcements, conversation'''

7:00 '''Interactive Discussions (Come and ask your questions!)'''

Attendee interaction is always mentioned as a high value at meetings and was great at the MetroWest meetings, so we're doing that at Akamai this month. Some discussion starters so far: SSL certificate impacts from CA/Browser alliance decisions and SHA1 weakness; mutual (client) SSL, javascript client and server side; what the heck is threat intelligence, dev ops and faster secure SDLC.

'''July 2015''' - Metrowest

When: Wednesday, July 20, 7:00 pm

Location: Constant Contact, Innovation Center, Reservoir Place, 1601 Trapelo Road, Waltham, MA 02451

7:00 '''News, views, announcements, conversation'''

7:30 '''Access in Maliceland - Risk Based Access Control''' - '''Gunnar Peterson'''

John Lambert observed attackers win because while defenders think in lists, attackers think in graphs. Access control systems divide the system a priori into secure and insecure states. But that’s only worth the paper its printed on. A Attackers see the system as it is, for attackers, the access control scheme is the beginning of the game not the end. Determined attackers seek out access control models and then find holes that they can leverage. Access control systems that purport to protect the system are built on assumptions from which reality diverges. Application security needs a new approach to access control- adding feedback loops for risk based decisions, fine-grained, dynamic access control.

Security is a business with a very long list of issues and requirements. The spreadsheets are miles long. This makes it essential to find reusable solution patterns that can address multiple problems.This presentation looks at both medium term improvements and code examples to improve access control decisions and overall security today

Gunnar Peterson ([https://twitter.com/oneraindrop @oneraindrop]) focuses on security architecture consulting and training. Experience includes Associate Editor for IEEE Security & Privacy Journal, a Microsoft MVP for App security, an IANS Research Faculty member, a Securosis Contributing Analyst, and a Visiting Scientist at Carnegie Mellon Software Engineering Institute. He maintains a popular information security blog at http://1raindrop.typepad.com.

'''July 2015''' - Cambridge

When: Wednesday, July 8, 6:30 pm ''NOTE: It's the second Wednesday this month.''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''Interactive Discussions (Come and ask your questions!)'''

'''June 2015'''

When: Wednesday, June 3, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''Put Down the Megaphone: Effective Security Advocacy Without the Shouting''' - '''Darren Meyer'''

10 years’ experience in the InfoSec community--including work with organizations in many verticals, in sizes ranging from startups to Fortune 50 enterprises, leading Application Security teams, building and delivering security instruction to developers, managers, and InfoSec professionals—has taught me the importance of crafting advocacy for different audiences. In this talk, I share my experiences in learning to be an effective advocate with three key audiences: developers, management, and non-technical staff.

Darren is an Application Security advocate and researcher, technology hobbyist, and maker. He loves to learn, teach, nerd out, and inflict terrible puns on people. His background includes logistics, software development, and an assortment of information security roles including leading AppSec programs and professional security instruction targeting developers, managers, and InfoSec professionals.

'''May 2015'''

When: Wednesday, May 6, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''How the crowd is discovering critical vulns missed by traditional methods''' - '''Leif Dreizler'''

State of the art security programs are turning to bug bounties to leverage a vast array of skill-sets and knowledge. Learn why these programs work, when to deploy them, and how you can bring these new application security testing capabilities into your own organization. The speaker will discuss real world examples from bug bounties and focus on cases where business logic flaws and high priority vulnerabilities were found ... even with existing security testing processes in place.

Attendees will learn:

Testing methods deployed by our crowd that help them find bugs the scanners miss

Examples of the high quality of bugs our crowd is finding, including P1'sTrends which vulnerability types are found most often and whyWhat is the ROI on the pay for performance modelWhere does the SDLC merge into crowdsourced testing

Leif Dreizler is a Senior Security Engineer at Bugcrowd, the innovator in crowdsourced security testing for the enterprise. Prior to joining Bugcrowd, Leif was a Senior Application Security Engineer at Redspin, performing application security assessments. During his time at Redspin he also served as the Application Team Lead, liaising with clients at the engineering and sales level. He has also made minor contributions to the Firebug project. Leif attended the University of California, Santa Barbara where he studied Computer Science. Leif recently spoke to the NYC Security Meet-up group.

'''April 2015'''

When: Wednesday, April 1, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

Jim Weiler Will show some actual examples and patterns of SQL Injection attempts

7:00 '''Are You An Imposter? Me too!''' - '''Patrick Laverty'''

Many people in the information security field feel like a fraud, or an imposter. In reality, we often know far more, and are capable of far more than we believe we do. There is so much to know and we constantly hear about the latest groundbreaking research done by others, which makes us feel less important or worthy. Let’s talk about what Imposter Syndrome is, its prevalence, and then we can start to realize just how capable we are and go forward with the confidence in the field.

'''March 2015'''

When: Wednesday, March 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''Prioritizing Web Application Vulnerabilities – A Hacker’s Perspective''' - '''Nick Silver'''

The best application risk models capture not only the technical risk factors, but also the business context in which an asset lives. Traditionally, this is done by auditing application owners on an array of questions in order to properly classify the asset and its data – but that takes time which could be better spent elsewhere. We interviewed dozens of hackers and asked them which vulnerabilities they would look for first depending on the type of attack they wanted to carry out. We’ll walk through several examples of how to use this data as a shortcut means for prioritizing risk without the need for any pesky audit questionnaires.

Nick Silver is a Senior Solutions Architect with WhiteHat Security. He is responsible for translating business requirements into technical ones and assisting businesses in implementing web security programs. Previously, Nick led a team in WhiteHat’s Threat Research Center where they were responsible for testing more than 2,000 of their customers’ websites for vulnerabilities.

'''February 2015'''

When: Wednesday, February 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News review, announcements''' - '''Jim Weiler'''

7:00 '''Incident Response and Web Application Security - Stories from the Trenches''' - '''Fred House and Joe Ceirante'''

Mandiant has conducted numerous incident response engagements throughout its history, including a record number of 200 incidents in 2014. Mandiant consultants Fred House and Joe Ceirante will discuss case studies and trends Mandiant has observed in relation to web application security.

Topics will include the types of threat actors that target web applications, the techniques they use to compromise web applications, and the activities they perform once inside the network. Techniques for detecting and mitigating web compromises will also be reviewed. All content will be derived from the real-world compromises that Mandiant has investigated.

'''January 2015'''

When: Wednesday, January 7, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News review, risk analysis of Poodle''' - '''Jim Weiler'''

7:00 '''How a Hacker Views Your Web Site''' - '''Patrick Laverty'''

''The most popular presentation of BASC 2014''

As defenders, we have to be right 100% of the time where an attacker only needs to be right once. The attack surface of a modern web site is incredibly large and we need to be aware of all of it. Additionally, individual attacks may not always be effective but sometimes using them together can gain the desired effect. In this talk, we’ll take a look at the whole attack surface for a typical web site and the various ways that an attacker will use to compromise a site.

'''December 2014'''

When: Wednesday, December 3, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News and Views You Can Use and Abuse''' - '''Jim Weiler'''

* Some thoughts and analysis on some current app security news and other stuff
* Adobe password breach
* Reducing Web Application Firewall SQL injection false positives

7:15 '''Swift and Security''' - '''Ming Chow'''

Apple is pushing its new programming language Swift for iOS development and for many good reasons. This talk will discuss what the language has right in terms of security, the old and new security pitfalls, and what developers need to be aware of moving forward with using the new language. The fact to the matter is, iOS isn't going away, iOS developers will need to learn and use Swift, and there will be a big rush of Swift-based apps: we might as well learn how to do it right the first time around.

Ming Chow is an Instructor at the Department of Computer Science, Tufts University. Ten years of web development experience.
Specialties: Web and Mobile Development, Web and Mobile Security

'''July 2014'''

Topics: '''Grails Security''' and '''Validating Cross-Site Scripting Vulns with xssValidator'''

Presenters: '''Cyrus Malekpour''' and '''John Poulin'''

When: Tuesday, July 8, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic 1: ''Grails Security''

Grails is a framework developed for Groovy in the vein of Rails for Ruby. It provides a lot of features for web app security, but does it do enough? What might you need to implement yourself, and what might be provided? This presentation will discuss tips on securing Grails applications, including tools that the framework provides by default for security. It'll also discuss several shortcomings in the current toolset, and how you can avoid them.

Cyrus Malekpour (@cmalekpour) is currently interning at nVisium, working on web app development and security. He's currently an undergraduate student at the University of Virginia, where he's studying computer science with an emphasis on security and backend development.

Topic 2: ''Validating Cross-Site Scripting Vulns with xssValidator''

xssValidator is a tool developed to automate the testing and validation of Cross-Site Scripting (xss) vulnerabilities within web applications. Automated scanners tend to report large amounts of false-positives, and as consultants we're forced spending our time trying to verify these findings. xssValidator leverages scriptable web-browsers such as PhantomJS and Slimer.js to automatically validate these findings.

John Poulin is an application security consultant for nVisium who specializes in web application security. He worked previously as a web developer and software engineer that focused on building multi-tier web applications. When he's not hacking on web apps, John spends his time building tools to help him hack on web apps! You can find him on twitter: @forced_request and on myspace: REDACTED.

'''June 2014'''

Topic: '''Training: SQL Injection and the OWASP Zed Attack Proxy (ZAP)'''

Presenters: '''Rob Cheyne and Jim Weiler'''

When: Wednesday, June 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 - general networking, news discussion, announcements.

7:00 - main presentations

The June 4th meeting will be the second in our series of 2014 training meetings. Rob Cheyne will continue explaining and exploring SQL Injection by conducting an actual injection attack.

This will be a demo-based discussion to get into the mindset of an attacker, and show how an attacker goes after a site. Demo will include:

* BurpProxy demo
* Common authentication flaws
* SQL Injection Demo that shows the process and how it builds to a full compromise

'''Rob Cheyne''' is currently CEO of Big Brain Security. In addition to security consulting for Fortune 500 customers, he was the author of LC4, a version of the award-winning L0phtCrack password auditing tool, and he also worked on the code scanning technology that was eventually spun off as Veracode. Rob was at @stake from the very first customer all the way through to the $50M acquisition by Symantec.

'''Jim Weiler''' will introduce the OWASP Zed Attack Proxy (ZAP). This is a very powerful free OWASP intercepting proxy that lets you see, analyze, change, replay etc. every browser request and response, analyze your session, scan and attack web sites, save the results and run reports. We can't cover all the functionality but we'll show some practical tips and techniques.

Pizza, salad and soda courtesy of Akamai

'''March 2014'''

Topic: '''Training: SQL Injection, WebGoat, Cross Site Request Forgery'''
Presenter: '''Benjamin Lerner'''
When: Wednesday, March 5, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

There will be three training sessions:

One will be on SQL Injection - intro, detection, prevention, scanning and false positives. This is the most serious web application vulnerability.

The second will be on OWASP WebGoat. WebGoat is a deliberately insecure web application maintained by OWASP designed to teach web application security lessons. You can install and practice with WebGoat in either J2EE or in ASP.NET. In each lesson, users must demonstrate their understanding of a security issue by exploiting a real vulnerability in the WebGoat applications. There are hints and 39 different lesson plans on various vulnerabilities and technologies. We won't cover all of them of course!

The third will be on Cross Site Request Forgery - not a hack really, it's just the way the web works. But it causes apps to do legitimate things that you didn't ask them to do.

Pizza and drinks provided by Akamai.

'''January 2014'''

When: Wednesday, January 8, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic: '''JavaScript Verification: From Browsers to Pages'''

Modern web browsers implement a "private browsing" mode that is intended to leave behind no traces of a user's browsing activity on their computer. This feature is in direct tension with support for *extensions*, which let users add third-party functionality into their browser. I will discuss the scope of this problem, present our approach to verifying extensions' compliance with private browsing mode, and sketch our findings on several real, third-party extensions. I will then briefly describe the toolkit underlying our approach, and end with a sketch of a newer project, adapting this approach to the very different-seeming problem of statically catching errors when using the jQuery library.

Presenter: '''Benjamin Lerner'''

Benjamin Lerner has just completed a post-doctoral research position in the PLT group at Brown University, and is now a lecturer at Northeastern University. His research examines the challenges of analyzing client-side web programming, from the behavior of web pages down through the semantics of the browser. He received a PhD in Computer Science from the University of Washington in 2011, building a platform to analyze conflicts between browser extensions, and a B.S. in Computer Science and Mathematics from Yale University.

'''November 2013'''

When: Wednesday, November 6, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic: '''Attacking iOS Applications'''

Slides: [http://www.slideshare.net/kfosaaen/i-os-gcandpb On slideshare]

This presentation will cover the basics of attacking iOS applications (and their back ends) using a web proxy to intercept, modify, and repeat HTTP/HTTPS requests. (The proxy used during research was Burp; however, any HTTP intercepting proxy such as OWASP ZAP could be used) From setting up the proxy to pulling data from the backend systems, this talk will be a great primer for anyone interested in testing iOS applications at the HTTP protocol level. There will be a short (2 minute) primer on setting up the intercepting proxy, followed by three practical examples showing how to intercept data headed to the phone, how to modify data heading to the application server, and how to pull extra data from application servers to further an attack. All of these examples will focus on native iOS apps (Game Center and Passbook) and/or functionality (Passbook Passes).

Presenter: '''Karl Fosaaen'''

Karl is a senior security consultant at NetSPI. This role has allowed Karl to work in a variety of industries, including financial services, health care, and hardware manufacturing. Karl specializes in network and web application penetration testing. In his spare time, Karl helps out as an OPER at THOTCON and a swag goon at DEF CON.

'''October 2013'''

When: Wednesday, October 2, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic: '''Abusing NoSQL Databases'''

The days of selecting from a few SQL database options for an application are over. There is now a plethora of NoSQL database options to choose from: some are better than others for certain jobs. There are good reasons why developers are choosing them over traditional SQL databases including performance, scalabiltiy, and ease-of-use. Unfortunately like for many hot techologies, security is largely an afterthought in NoSQL databases. This short but concise presentation will illustrate how poor the quality of security in many NoSQL database systems is. This presentation will not be confined to one particular NoSQL database system. Two sets of security issues will be discussed: those that affect all NoSQL database systems such as defaults, authentication, encryption; and those that affect specific NoSQL database systems such as MongoDB and CouchDB. The ideas that we now have a complicated heterogeneous problem and that defense-in-depth is even more necessary will be stressed. There is a common misconception that SQL injection attacks are eliminated by using a NoSQL database system. While specifically SQL injection is largely eliminated, injection attack vectors have increased thanks to JavaScript and the flexibility of NoSQL databases. This presentation will present and demo new classes of injection attacks. Attendees should be familiar with JavaScript and JSON.

Presenter: '''Ming Chow'''

Ming Chow (@tufts_cs_mchow) is a Lecturer at the Tufts University Department of Computer Science. His areas of work are in web and mobile engineering and web security. He teaches courses largely in the undergraduate curriculum including the second course in the major sequence, Web Programming, Music Apps on the iPad, and Introduction to Computer Security. He was also a web application developer for ten years at Harvard University. Ming has spoken at numerous organizations and conferences including the High Technology Crime Investigation Association - New England Chapter (HTCIA-NE), the Massachusetts Office of the Attorney General (AGO), John Hancock, OWASP, InfoSec World (2011 and 2012), DEF CON 19 (2011), the Design Automation Conference (2011), Intel, and the SOURCE Conference (Boston 2013). Ming's projects in information security include building numerous CTF challenges, Internet investigations, HTML5 and JavaScript security, and Android forensics.

'''September 2013 - Joint Meeting with [http://www.meetup.com/Boston-cloud-services/ Boston Cloud Services]'''

When: Tuesday, September 10, 6 pm

Location: Microsoft NERD Center ''(not our usual location)''

'''Note: This is a joint meeting. Please register at [http://www.meetup.com/Boston-cloud-services/ the Boston Cloud Services meetup page] if you plan to attend.'''

There will be two presentations at this meeting:

Topic: '''People Centric Security (PCS)'''

Presenter: '''Nick Stamos'''

People Centric Security (PCS) is a new security model, presented as part of Gartner's Maverick Research 2 year ago. PCS is well suited for Cloud Business/Consumer services such as Dropbox, Google Drive, SkyDrive, etc. PCS enables users to have what they desire, and provides enterprises what they require for data governance and compliance. Nick Stamos co-founded his fourth company, nCrypted Cloud in July of 2012. His past startups include Verdasys, Phase Forward (IPO FY2004, $685M Oracle Acquisition 2010), and Amulet. He studied at Tufts University where he received a BSEE and MSEE.

Topic: '''SSL Certs'''

Presenter: '''Jim Weiler'''

Practical experiences with issuing and risk assessing SSL certs for enterprise applications on a cloud provider: who creates the CSR, how do you protect the private key on the cloud server, certs on cloud provider managed load balancers vrs 3rd party managed app servers, roles and responsibilities of cloud IT, 3rd party developer IT, enterprise IT and service providers. Jim Weiler is Application Security Architect at Starwoods Hotels and the Chapter Leader of OWASP Boston.

'''July 2013 - Doubleheader!'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, July 10, 6:30 pm

Topic: '''RailsGoat'''

Presented by: '''Ken Johnson'''

Abstract: While working to secure rails applications in a truly Agile development environment, it became clear that the Rails and Ruby ecosystem needed attention from the security community in the form of free and open training, and the events that have transpired within the last few months have only reinforced that belief. [http://railsgoat.cktricky.com/ RailsGoat] is an attempt to bring attention to both the problems that most frequently occur in Rails as well as the solutions for remediation. To accomplish this, we've built a vulnerable Rails application that aligns with the OWASP Top 10 and can be used as a training tool for Rails-based development shops.

Topic: '''PhoneGap on Android'''

Presented by: '''Jack Mannino'''

Abstract: PhoneGap is a widely used framework that allows developers to rapidly build cross-platform mobile applications using HTML5, JavaScript, and CSS. Using PhoneGap plugins, developers can call native platform APIs from browser-like applications using JavaScript. This approach introduces vulnerabilities that are not typically as prevalent within native Android applications, warranting a fresh look at the way we view mobile applications. In this presentation, we will take a deep look at the Android implementation of the framework and we will examine the overall attack surface for applications. Real-world examples of vulnerable applications will be demonstrated as well in order to provide context, entertainment, and enjoyment.

About the Speakers:

Ken Johnson is the former Manager of LivingSocial.com's application security team where he built their security program before leaving for his true home as the CTO of nVisium Security, a VA-based application security company. Ken is the primary developer of the Web Exploitation Framework and contributes to other open source application security projects as often as time permits. He has spoken at AppSec DC 2010 and 2012, OWASP NoVA and Phoenix chapters, Northern Virginia Hackers Association (NoVAH) and is a contributor to the Attack Research team.

Jack Mannino is the CEO of nVisium Security, a VA-based application security company. At nVisium, he helps to ensure that large corporations, government agencies, and software startups have the tools they need to build and maintain successful security initiatives. He is an active Android security researcher/tinkerer, and has a keen interest in identifying security issues and trends on a large scale. Jack is a leader and founder of the OWASP Mobile Security Project. He is the lead developer for the OWASP GoatDroid project, and is the chairman of the OWASP Northern Virginia chapter.

'''June 2013'''

Topic: '''We see the future…and it isn’t pretty'''

Presented by: '''Andrea Mulligan, Sr. Director at Veracode'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, June 5, 6:30 pm

In this session Andrea presents research findings from the State of Software Security Report, which offers a before the breach look at security by examining the flaws commonly found in applications of all kinds. She will also examine what the research findings mean for security, predict how these flaws could cause history to repeat itself, and discuss how security pros can help change the future.

'''May 2013'''

Topic: '''Systems Thinking + Web Security'''

Presented by: '''Akamai'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, May 1, 6:30 pm

Akamai will present on ‘Systems Thinking + Web Security’. There will also be an audience review exercise facilitated by the Akamai presenters. This is a great chance to hear some interesting perspectives on web security from Akamai, who handles about one third of all internet traffic.

'''April 2013'''

Topic: '''Go Fast. Be Secure: Effectively Govern the Use of Open Source Components Throughout the SDLC'''

Presented by: '''Sonotype'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, April 3, 6:30 pm

* Open Source Software (OSS) Component supply chain complexities and realities. Open source is constantly changing and knowing the version in your software, as well as the current version history of the component (how do you show an auditor you are using a current version) is important.
* Open Source Consumption Patterns from the Central Repository. Which versions are the most popular can tell you which versions are the most stable, useful, secure etc.
* OWASP Top 10 (A9) - Using Components with Known Vulnerabilities. To decide on the risk of OSS components with vulnerabilities, you need to know the vulnerabilities, their severity and which components they occur in as well as where in the code dependency tree they are.
* OSS Security, Quality and License policies must be woven into the development process. Knowing the number and type of open source licenses in your software can be important to the legal standing of your code and if it conflicts with any corporate standards. The licensing is also important in order to know the restrictions on changing the software.
* OSS Component Policy Examples
* Example Application Compositions Reports
* Example Use cases IDE, CI, repository, production applications
* Discussion

About Sonatype:

Sonatype operates the Central Repository, the industry's primary source for open-source components, housing more than 400,000 components and serving more than five billion requests per year from more than 60,000 organizations. The company has been a pioneer in component-based software development since its founding by Jason van Zyl, the creator of the Apache Maven build management system and the Central Repository.

'''March 2013'''

Topic: '''What is BSIMM?'''

Speaker: '''Nabil Hannan'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Nabil is Director of Vulnerability Assessments and Managing Consultant at Cigital.

The purpose of the BSIMM is to quantify the activities carried out by real software security initiatives. BSIMM is a study of the secure development practices of over 50 organizations, analyzed along the dimensions that were found in the data, not along preconceived ideas of what secure development should be.

BSIMM describes the work of 974 software security group members working with a satellite of 2039 people to secure the software developed by 218,286 developers.

The BSIMM describes 111 activities that any organization can put into practice. The activities are described in twelve practices grouped into four domains. Associated with each activity is an objective.

'''February 2013'''

Topic: '''BroBot'''

Speaker: '''Eric Kobrin, Akamai'''

When: Wednesday, February 6, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Eric Kobrin is a Senior Security Architect in the Infosec organization of Akamai Technologies, the global leader in Cloud-based application acceleration and content delivery. Eric has been involved in Software Architecture for over 15 years, having worked at such companies and IBM, Velocitude and eDiets.com. He has a passion for programming languages, security, and software performance and has worked in all layers of the software stack from hypervisors to complex servers and web applications. Eric's works have been published, presented at international conferences and patented.

His presentation will provide an analysis of the BroBot DDOS attacks, including discussion of:

* Vulnerable system discovery
* Zombie compromise
* Control structure
* Attack traffic
* Mitigation steps

'''January 2013'''

Topic: '''Third-Party Application Analysis: Best Practices and Lessons Learned'''

Speaker: '''Chad Holmes, Veracode'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Chad Holmes will present details of the work Veracode has been doing with their 3rd Party program, discuss the technical and business challenges that have arisen during that time and lead a discussion on what team members can do to help drive adoption of security best practices across their vendor community.

The flow of the presentation is designed to drive discussion within an audience – both from a technical and business perspective with some anecdotal stories. Chad wants this to be an interactive discussion so he’ll have questions and you should bring yours I’ve already sent him some. The order of the presentation is:

· Adoption rates of externally developed software

· The risk within those apps

· Some deeper stats on what “3rd party” really means (total outsourcing/total COTS produced/open source/imported libraries/etc)

· Some raw data about our experiences (to show this is based on a large sample size rather than “Look how awesome Veracode is!”)

· Challenges that will be faced (business, intellectual property, policy, analysis capabilities, etc)

· Best Practices for high rates of adoption

· Lessons Learned and Recommendations

Chad Holmes has over 10 years of software development and application security experience. During his time at Veracode, Chad has lead the redesign and execution of the third-party analysis process to allow for a more streamlined approach while still addressing common ISV intellectual property concerns. In addition to his third-party analysis responsibilities, Chad's previous work as a Security Program Manager has lead to the successful roll out and improvement of multiple corporate application security groups.

'''June 2012'''
Location - Microsoft Waltham (201 Jones Rd., Sixth Floor Waltham, MA)

Speaker '''Will Vandevanter - Rapid 7'''

'''Fingerprinting web applications of all kinds'''

This turbo talk will introduce a new Metasploit module that fingerprints "known" web applications, attempts the default credentials for the application, and runs an associated exploit or authenticated access module if applicable. Some example fingerprints in the database target common enterprise web applications including Microsoft products (Outlook Web Access, Sharepoint), printers (Xerox Document Centre), security cameras, routers, and others.

Will Vandevanter is a senior penetration tester and researcher at Rapid7. His focus interests include web application security and secure code. He has previously spoken at Defcon, SOURCE, BSides LV, and other conferences.

'''May 31 2012'''

Location - Jobspring, Boston. 545 Boylston st.

Speaker - '''Glenn Gramling, Vice President, Cenzic'''

“Cloudy with a Chance of Hack”

Cloud computing is a cost effective and efficient way for enterprises to automate their processes. However organizations need to be aware of the pitfalls of the many cloud solutions out there - one of the main being security. Most cloud applications were built for ease of use and without security necessarily in mind. Companies need to be asking their solution providers about the security measures used in developing the application and get an independent verification to make sure there are no gaping holes. With over 75% of attacks occurring through the Web, any attack through these applications can lead to leakage of confidential information and embarrassment. In this session, we'll give attendees tips and tricks to prepare them for the potential of "stormy weather."

Glenn Gramling is responsible for global sales and business development for Cenzic’s application security.

'''April 11, 2012'''

Location - Microsoft Waltham (201 Jones Rd., Sixth Floor Waltham, MA)

Speaker - '''David Eoff, Senior Product Marketing Manager, HP Enterprise Security'''

David is a Senior Product Marketing Manager, within the Enterprise Security Products division of HP focused on Fortify application security. His 18+ years of background in software and hardware enterprise marketing provides a solid foundation for his marketing of the HP security solutions.

Prior to joining Fortify in 2009 and being acquired by HP, David ran Firewall and IPS marketing for the Security division of Nokia Corporation. In addition, he has held multiple positions in product marketing, product management, channel marketing and sales while working for Oracle, EMC, Legato, BMC Software and several start-ups.

Topic - '''Gray, the New Black: Gray-Box Vulnerability Testing'''

Over the years, two key techniques have emerged as the most effective for finding security vulnerabilities in software: Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST). While DAST and SAST each possess unique strengths, the “Holy Grail” of security testing is thought to be “hybrid” – a technique that combines and correlates the results from both testing methods, maximizing the advantages of each. Until recently, however, a critical element has been missing from first generation hybrid solutions: information about the inner workings and behavior of applications undergoing DAST and SAST analysis.

This presentation will introduce you to the next generation of hybrid security analysis – what it is, how it works, and the benefits it offers. It will also address (and dispel) the claims against hybrid, and leave you with a clear understanding of how the new generation of hybrid will enable organizations to resolve their most critical software security issues faster and more cost-effectively than any other available analysis technology.

'''March 8, 2012, with the Boston Security Meetup group'''

Location - [http://maps.google.com/maps?q=Jobspring+Partners,+Boylston+Street,+Boston,+MA&hl=en&sll=42.362243,-71.081628&sspn=0.019549,0.037594&oq=jobspring&t=v&hq=Jobspring+Partners,&hnear=Boylston+St,+Boston,+Massachusetts&z=17 JobSpring, Boylston St.]

Topic - '''Corporate Espionage for Dummies: The Hidden Threat of Embedded Web Servers'''

Speaker - VP for Security Research at ZScaler, along with other speakers at the security meetup.

Today, everything from kitchen appliances to television sets come with an IP address. Network connectivity for various hardware devices opens up exciting opportunities. Forgot to lower the thermostat before leaving the house? Simply access it online. Need to record a show? Start the DVR with a mobile app. While embedded web servers are now as common as digital displays in hardware devices, sadly, security is not. What if that same convenience exposed photocopied documents online or allowed outsiders to record your telephone conversations? A frightening thought indeed.

Software vendors have been forced to climb the security learning curve. As independent researchers uncovered embarrassing vulnerabilities, vendors had little choice but to plug the holes and revamp development lifecycles to bake security into products. Vendors of embedded web servers have faced minimal scrutiny and as such are at least a decade behind when it comes to security practices. Today, network connected devices are regularly deployed with virtually no security whatsoever.

The risk of insecure embedded web servers has been amplified by insecure networking practices. Every home and small business now runs a wireless network, but it was likely set up by someone with virtually no networking expertise. As such, many devices designed only for LAN access are now unintentionally Internet facing and wide open to attack from anyone, regardless of their location.

Leveraging the power of cloud based services, Zscaler spent several months scanning large portions of the Internet to understand the scope of this threat. Our findings will make any business owner think twice before purchasing a 'wifi enabled' device. We'll share the results of our findings, reveal specific vulnerabilities in a multitude of appliances and discuss how embedded web servers will represent a target rich environment for years to come.

'''December 13, 2011, 6:30, Microsoft NERD, Cambridge, Horace Mann Room'''

'''Jeremiah Grossman – Founder and CTO WhiteHat Security'''

Directions: http://microsoftcambridge.com/About/Directions/tabid/89/Default.aspx

'''September 14 2011'''

'''Dinis Cruz - OWASP O2 Platform'''

The O2 Platform is focused on automating application security knowledge and workflows. It is a library of scriptable objects specifically designed for developers and security consultants to be able to perform quick, effective and thorough source code-driven application security reviews (blackbox + whitebox).

'''September 7 2011'''

'''Adriel Desautels – Differences between Penetration Testing and Vulnerability Scanning'''

'''July 2011'''

'''Anurag Agarwal, the founder of MyAppSecurity'''

'''Session 1 - Managing Risk with Threat Modeling'''
Threat Modeling can help by guiding the Application Development Teams to ensure your Security Policies get properly coded into the Applications at time of Development. By creating pre-approved methods of coding for your development teams, and applying them in a repeatable and scalable process, you can assist your development teams in building a secure application easily and effortlessly.

'''Session 2 - False Positive, False Negative and False Sense of Security'''
This interactive session will talk about the pros and cons of using black box testing tools and discuss their effectiveness in building a mature software security program.

'''Thursday June 2'''

Location - '''Microsoft NERD''' - http://microsoftcambridge.com/About/Directions/tabid/89/Default.aspx

'''Topic - Bringing Sexy Back: Defensive Measures That Actually Work'''

Presenter - Paul Asadoorian, Founder & CEO, PaulDotCom Enterprises

There is a plethora of information available on how to break into systems, steal information, and compromise users. As a penetration tester, I have performed testing on a regular basis that reveals severe security weaknesses in several organizations, and many of my peers have reported on the same. However, once you "own" the network and report on how you accomplished your goals, now what? Sure, we make defensive recommendations, but consistently it has been proven that security can be bypassed. Not enough focus is given to what works defensively. We have a lot of technology at our disposal: firewalls, intrusion detection, log correlation, but it provides little protection from today's threats and is often not implemented effectively. This talk will focus on taking an offensive look at defense. Applying techniques that are simple, yet break the mold of traditional defensive measures. We will explore setting up "traps" for attackers, slowing them down with simple scripts, using honeypots, planting bugs, and most importantly tying these methods to "enterprise security". This talk will also include real-world examples of the techniques in action from a live, heavily attacked site. Topics will include:

*Using wireless “attacks” on the attackers
*Implementing the Metasploit Decloak engine to find the attackers
*Setting traps to detect web application attacks
*Integrating results into your enterprise log management tool

The goal of this talk is to make defense “sexy”…

'''Presenter Bio'''

Paul Asadoorian is currently the "Product Evangelist" for Tenable Network Security, where he showcases vulnerability scanning and management through blogs, podcasts and videos. Paul is also the founder of PaulDotCom, an organization centered around the award winning "PaulDotCom Security Weekly" podcast that brings listeners the latest in security news, vulnerabilities, research and interviews with the security industry's finest. Paul has a background in penetration testing, intrusion detection, and is the co-author of "WRT54G Ultimate Hacking", a book dedicated to hacking Linksys routers.

'''Thursday May 26'''

Location - Microsoft Waltham (201 Jones Rd., Sixth Floor Waltham, MA)

'''Topic - OWASP Top 10 issue #4 – Insecure Direct Object Reference'''

Presenter - Jim Weiler, Sr. Mgr. Information Security, Starwood Hotels and President of OWASP Boston

Jim Weiler will discuss threat models, risks and various remediations of issue #4 in the 2010 OWASP Top 10 – Insecure Direct Object References.

'''Topic - A Web-Application Architecture for Regulatory Compliant Cloud Computing'''

Presenter - Arshad Noor, StrongAuth

The emergence of cloud-computing as an alternative deployment strategy for IT systems presents many opportunities, yet challenges traditional notions of data-security. The fact that data-security regulations are developing teeth, leaves information technology professionals perplexed on how to take advantage of cloud-computing while proving compliance to regulations for protecting sensitive information.

This presentation presents an architecture for building the next generation of web-applications. This architecture allows you to leverage emerging technologies such as cloud-computing, cloud-storage and enterprise key-management (EKM) to derive benefits such as lower costs, faster time-to-market and immense scalability with smaller investments - while proving compliance to PCI-DSS, HIPAA/HITECH and similar data-security regulations.

'''Presenter Bio'''

Arshad Noor is the CTO of StrongAuth, Inc, a Silicon Vally-based company that specializes in enterprise key management. He is the designer and lead-developer of StrongKey, the industry's first open-source Symmetric Key Management System, and the KeyAppliance - the industry's first appliance combining encryption, tokenization, key-management and a cryptographic hardware module at an unprecedented value. He has written many papers and spoken at many forums on the subject of encryption and key-management over the years.

''' CANCELLED '''

'''Topic – Secure Application design and Coding''' -- CANCELLED

Presenter - Josh Abraham, Rapid 7

'''Speaker Bio '''

'''April 2011'''

Ed Adams Security Innovation -- the new OWASP Exams Project and the work being done by the OWASP Academies Working Group

<br>

'''March 2011'''

Josh Abraham, Rapid 7

Owning the world, one mobile app at a time, and web services pen testing.

<br>

'''Febrary 2011'''

Rob Cheyne, CEO of Safelight Security -

Security Leadership series: Delivering a successful security presentation

<br>

'''December 2010'''

Application Architecture Security Assessment - Second session

Rob Cheyne, CEO SafeLight Security Advisors

<br>

'''November 2010'''

Open SAMM – Software Assurance Maturity Model

Shakeel Tufail is the Federal Practice Manager at Fortify, an HP company.

<br>

'''October 2010'''

Rob Cheyne, CEO SafeLight Security Advisors Overview: In this highly interactive two-part workshop, Rob Cheyne of Safelight Security will show you the basics of conducting a real-world architecture & design review. This workshop draws from Safelight's Security Architecture Fundamentals training course, a two-day course frequently used to teach Fortune 500 companies how to look at their system architectures from both the hacker's and the designer’s point of view.

'''July 2010'''

Lightning Talk – Rob Cheyne, CEO Safelight Security Advisors In this installment of the Safelight lightning talks series, Rob will present the basics of a Cross-site Request Forgery (CSRF).

Main Presentation - Drive-by Pharming with MonkeyFist

Joey Peloquin - Director of Application Security, Fishnet Security

'''June 2010'''

Rob Cheyne Lightning Talk - topic to be announced

Main Presentation - Ryan Barnett The Web Hacking Incident Database (WHID) is a Web Application Security Consortium project dedicated to maintaining a list of web applications related security incidents. Ryan Barnett is director of application security research at Breach Security where he leads Breach Security Labs.

'''May 2010'''

Rob Cheyne Lightning Talk - SQL Injection

Vinnie Liu - Data Exposure, New Approaches to Open Source Intelligence Techniques, and Incident Handling

<br>

'''April 2010'''

Dan Hestad Security Innovation Dan will be talking about his experiences with PCI and web applications, and answering questions about do's and don'ts of acceptable PCI practices in web applications.

'''March 2010'''

Zack Lanier - Disclosure Samsara, or "the endless vulnerability disclosure debate"

http://n0where.org/talks/samsara_20100310.html

http://n0where.org/talks/samsara_20100310.pdf (very large PDF)

<br>

'''February 2010'''

Rob Cheyne of Safelight Security Advisors; New Technology, Same Old Vulnerabilities

<br>

'''January 2010 at Microsoft NERD, Cambridge'''

Josh Abraham, Rapid 7 Technologies

'''December 2009'''

Eric Bender, Cenzic

'''November 2009'''

Jim Weiler, Sr. Mgr. Information Security, Starwood Hotels - Web Application Vulnerability Scanners

Mush Hakhinian, Leader, Application Security Practice, IntraLinks - Secure coding with no money down using SONAR: unleashing the power of open-source code analysis tools

<br>

'''October 2009'''

Paul Schofield, Senior Security Engineer, Imperva - From Rivals to BFF: WAF & VA Unite

<br>

'''September 2009 at CORE Technologies, Boston'''

Paul Asadoorian, Pauldotcom.com

Alex Horan, CORE Security

<br>

'''May 2009'''

Joey Peloquin, Fishnet Security, Secure SDLC: The Good, the Bad and the Ugly [http://www.owasp.org/images/4/48/SecureSDLC-GoodBadUgly.pdf presentation pdf]

<br>

'''March 2009'''

Sabha Kazerooni, Security Compass - Exploit Me tools; Framework Level Threat Analysis

[http://www.owasp.org/images/5/5a/Security_Compass_Exploilt_Me.pdf ExploitMe Document]

[http://www.owasp.org/images/e/ef/Security_Compass_Framework-level_Threat_Analysis.pdf Framework Level Threat Analysis document]

Meeting Pizza Sponsor - Arcot

Arcot is a leader in online fraud prevention, strong authentication and eDocument security. Arcot's solutions are easily deployed, low-cost and extremely scalable, allowing organizations to transparently protect their users from fraud without changing user behavior or requiring expensive hardware.

Arcot can be contacted thru Michael Kreppein, michael.kreppein@arcot.com, 617-467-5200

'''December 2008'''

Brian Holyfield, Gothem Digital Science

Tamper Proofing Web Applications http://www.gdssecurity.com/l/b/2008/12/04/

'''June 2008'''

Jeremiah Grossman; Founder and CTO, Whitehat Security

Appetizer - Hacking Intranets from the Outside (Just when you thought your network was safe) Port scanning with JavaScript

Main Topic - Business Logic Flaws: How they put your Websites at Risk

'''March 2008'''

Chris Eng; Senior Director, Security Research, Veracode

Description – Attacking crypto in web applications

'''December 2007'''

Scott Matsumoto; Principal Consultant, Cigital

Description – You Say Tomayto and I Say Tomahto – Talking to Developers about Application Security

[https://www.owasp.org/images/5/5b/BostonOWASP200712-Cigital.pdf Cigital Presentation]

'''November 2007'''

Tom Mulvehill Ounce Labs

Description – Tom will share his knowledge and expertise on implementing security into the software development life cycle. This presentation will cover how to bring practicality into secure software development. Several integration models will be explored as well as solutions for potential obstacles

[https://www.owasp.org/images/f/f8/Ounce_OWASP_07NOV07ppt.zip Ounce presentation]

<br>

'''October 2007'''

George Johnson, Principal Software Engineer EMC; CISSP

An Introduction to Threat Modeling.

<br>

'''September 2007'''

Day of Worldwide OWASP 1 day conferences on the topic "Privacy in the 21st Century"

'''June 2007'''

Tool Talk - Jim Weiler - WebGoat and Crosssite Request Forgeries

Danny Allan; Director, Security Research, Watchfire

Topic: Exploitation of the OWASP Top 10: Attacks and Strategies

'''March 2007'''

Jeremiah Grossman, CTO Whitehat Security: Top 10 Web Application Hacks of 2006

<br>

'''January 2007'''

Dave Low, RSA the Security Division of EMC: encryption case studies

<br>

'''November 2006'''

<br>

'''September 2006'''

Mike Gavin, Forrester Research: Web Application Firewalls

<br>

'''June 2006'''

Imperva - Application and Database Vulnerabilities and Intrusion Prevention

Jim Weiler - Using Paros Proxy Server as a Web Application Vulnerability tool

<br>

'''May 2006'''

<br>

'''April 2006'''

Dennis Hurst; SPI Dynamics: A study of AJAX Hacking

Jim Weiler; OWASP Boston: Using Paros HTTP proxy, part 1. first meeting with all demos, no powerpoints!

<br>

'''March 2006'''

Mateo Meucci; OWASP Italy [http://www.owasp.org/images/8/8c/Anatomy_of_2_Web_App_Testing.zip Anatomy of 2 web attacks]

Tom Stracener; Cenzic Web Application Vulnerabilities

<br>

'''February 2006'''

Ron Ben Natan; Guardium CTO Database Security: Protecting Identity Information at the Source

<br>

'''January 2006'''

David Low, Senior Field Engineer: RSA Practical Encryption

<br>

'''December 2005'''

Paul Galwas, Product Manager: nCipher [http://www.owasp.org/docroot/owasp/misc/OWASP051207.ppt Enigma variations: Key Management controlled]

<br>

'''November 2005'''

Robert Hurlbut, Independent Consultant [http://www.owasp.org/docroot/owasp/misc/OWASP_Hurlbut_ThreatModelingforWebApplicaitons.zip Threat Modeling for web applications]

<br>

'''October 2005'''

Prateek Mishra, Ph.D. Director, Security Standards and Strategy: Oracle Corp Chaiman of the OASIS Security Services (SAML) Technical Committee - [http://www.owasp.org/docroot/owasp/misc/Federation-Introduction-Overview-01.ppt Identity Federation : Prospects and Challenges]

Ryan Shorter, Sr. System Engineer: Netcontinuum - Application Security Gateways

<br>

'''September 2005'''

Dr. Herbert Thompson, Chief Security Strategist: SecurityInnovation - How to Break Software Security

<br>

'''July 2005'''

Mark O'Neill, CTO: Vordel - [http://www.owasp.org/docroot/owasp/misc/MarkOneill.pdf Giving SOAP a REST? A look at the intersection of Web Application Security and Web Services Security]

'''June 2005'''

Arian Evans, National Practice Lead, Senior Security Engineer: Fishnet Security [http://www.owasp.org/conferences/appsec2005dc/schedule.html Overview of Application Security Tools]

<br>

'''May 2005'''

Patrick Hynds, CTO: Critical Sites - [http://www.owasp.org/docroot/owasp/misc/Passwords-Keys_to_the_Kingdom_Dev_V1.ppt Passwords - Keys to the Kingdom]

<br>

'''April 2005'''

Jonathan Levin - [http://www.owasp.org/docroot/owasp/misc/JLevinRandoms.pdf Of Random Numbers]

Jothy Rosenberg, Founder and CTO: Service Integrity - [http://www.owasp.org/docroot/owasp/misc/JothyRWebSvcsSec.ppt Web Services Security]

<br>

'''March 2005'''

Joe Stagner: Microsoft Let's talk about Application Security

<br>

'''Feb 2005'''

Application Security Inc. PowerPoint slides for the [http://www.owasp.org/docroot/owasp/misc/Anatomy+of+an+Attack.ppt Anatomy of a Database Attack.]

== Local Chapter Information ==

To find out more about the Boston chapter, just join the [http://lists.owasp.org/mailman/listinfo/owasp-boston OWASP Boston mailing list].

The chapter shipping/mailing address is:

OWASP Boston <br />
35 Wachusett Dr <br />
Lexington, MA 02421

== Links ==

[http://www.owasp.org/index.php/Reviews_of_security_podcasts Reviews of security podcasts]

[https://www.owasp.org/index.php/2017_BASC_Homepage Boston Application Security Conference 2017]

[[2016 BASC Homepage|Boston Application Security Conference 2016]]

[[2015 BASC Homepage|Boston Application Security Conference 2015]]

[[2014 BASC Homepage|Boston Application Security Conference 2014]]

[[2013 BASC Homepage|Boston Application Security Conference 2013]]

[[2012 BASC Homepage|Boston Application Security Conference 2012]]

[[2011 BASC Homepage|Boston Application Security Conference 2011]]

[[2010 BASC Homepage|Boston Application Security Conference 2010]]

== Boston OWASP Chapter Leaders ==

'''Contact'''

* Email the [mailto:boston-leaders@owasp.org chapter leaders].

'''President'''

* [mailto:jim.weiler@owasp.org Jim Weiler] 781 356 0067

'''Board of Directors'''

* [mailto:lindaleigh.aberdale@owasp.org LindaLeigh Aberdale]
* [mailto:mark.arnold@owasp.org Mark Arnold]
* [mailto:tom.conner@owasp.org Tom Conner]
* [mailto:mike.perez@owasp.org Mike Perez]
* [mailto:roy.wattanasin@owasp.org Roy Wattanasin]
* [mailto:pedro.marcano@owasp.org Pedro Marcano]
* [mailto:Mark.Schlepphorst@owasp.org Mark Schlepphorst]
* [mailto:Ori.Zigindere@owasp.org Ori Zigindere]
__NOTOC__

[[Category:Boston]]
[[Category:OWASP_Chapter]]
[[Category:Massachusetts]]

Boston

2019-04-28T20:53:07Z

Jweiler: /* Chapter Meetings --- Our Tenth Year */

{{Chapter Template|chaptername=Boston|extra=Follow @OWASPBOSTON on Twitter. The chapter leader is [mailto:boston@owasp.org Jim Weiler]. The Boston chapter is grateful for support from Constant Contact, Salesforce, Microsoft and Akamai for generously hosting space and their hospitality for various events.

__FORCETOC__

The Chapter would also like to thank our sponsors for their generous support.|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Boston|emailarchives=http://lists.owasp.org/pipermail/owasp-Boston}}

== Chapter Sponsor ==
[[File:SIlogostacked.png|Security Innovation|https://www.securityinnovation.com/]]

[[File:Veracode logo.png|Veracode|https://www.veracode.com/]]

== Boston Application Security Conference ==

[[Image:Boston-Banner-468x60.gif|link=2018_BASC_Homepage]] [[Image:twitter_32.png|link=https://twitter.com/@BASConf]] BASC 2019, the Boston Application Security Conference will take place 8:30am to 6:30pm on Saturday, October 19th at Microsoft, 5 Wayside Road, Burlington, MA. [[2018 BASC Homepage|Read more]]

== Chapter Meetings --- Our Fifteenth Year ==

We now use [http://www.meetup.com/owaspboston/ meetup] to organize meetings.

We meet whenever a speaker and a venue have available dates, 6:30 to 9 pm.

Everyone is welcome to come to any meeting, there is no signup or joining criteria, just come if it sounds interesting. Feel free to sign up to the [http://lists.owasp.org/mailman/listinfo/owasp-boston OWASP Boston mailing list]. This list is very low volume (2 - 3 emails/month); it is used to remind people about each monthly meeting, inform about local application security events and special chapter offers.

Upcoming Meetings

''January 29th, 2019'' - Cambridge [https://web.securityinnovation.com/owaspboston2019 Partnered with Security Innovation]

Location: [https://goo.gl/maps/w11GUuJJAbo Quick Base office]

5PM- '''Just bring your computer and evil inner-doer and you are ready to roll!'''

Security Innovation is teaming up with OWASP Boston to offer attendees a fun "find the vulnerabilities" game - CMD+CTRL Cyber Range - that shows how hackers break into websites and teaches the importance of secure coding habits.

The CMD+CTRL Cyber Range we will be using is called ShadowBank, a banking website where players compete to find vulnerabilities, score points, and move up the leaderboard. Leveraging cheat sheets, attack tables, and expert led training sessions, platers take their shot at stealing money, manipulating share prices, and conducting other nefarious acts.

=== Upcoming Training ===
TBD

=== Past Meetings ===
''June 14th, 2017'' - Burlington [https://www.meetup.com/owaspboston/events/240033562/ Meetup]

Location: [https://maps.google.com/maps?f=q&hl=en&q=5+Wall+St.%2C+Burlington%2C+MA%2C+us SalesForce (was Demandware) 5 Wall St., Burlington, MA]

Everyone should report to Akamai 90 Broadway in the lobby and indicate about the Meetup. Someone form the staff will escort them to the 12th floor.

5:30 - 6:15 - '''Chat, Chew and Brew'''

6:15 - 6:45 '''News, Announcements'''

Chapter and OWASP events and news, audience announcements, questions, application security news(Google and Symantec certs, HTML5, Chrome features, SDLC and Microservices, others?)

7:00 pm ''' Is RASP Ready?'''

Runtime Application Self-Protection is overhyped, according to many analysts and pundits. RASP promises applications that protect themselves - which sounds impossible - how can an application possibly protect itself? An agent that sits inside the app sounds like a deployment nightmare at worst, and a drain on the app at best. What’s the reality? Where are we now and what have we learned?

We’ve seen deployment successes and failures, and we will draw from those specific experiences to describe:
Where does RASP work?
* What applications are well-suited for RASP?
* What types (organizational structure, culture, or skillset) of organizations are well-suited for RASP?

What is the reality of RASP?
* Is RASP a deployment model or a feature set?
* How mature is RASP? Is it an over-hyped immature space, enterprise-ready, or somewhere in between?
* Which RASP capabilities do organizations use? And how do they validate those capabilities in their own environments?
* Can RASP replace the WAF?

We will conclude, not with a sales pitch, but some lessons learned on: the three must have attributes for RASP, some suggestions on good candidates for RASP – both types of teams and types of applications, and finally - if, how, and when to get started.

''Speaker'': Michael Feiertag, CEO and Co-Founder, tCell
Before co-founding tCell at the end of 2014, Michael led a string of successful products – most recently as head of products at Okta, and prior to that, as technology director at Blue Coat. Prior to Blue Coat, Michael held product management, engineering, and sales positions at several start-ups. Michael holds a B.S. from The University of Chicago, and an M.S. from the University of Maryland

'''May 2, 2017''' - Burlington [https://www.meetup.com/owaspboston/events/239130768/ Meetup]

Location: [https://maps.google.com/maps?f=q&hl=en&q=5+Wall+St.%2C+Burlington%2C+MA%2C+us SalesForce (was Demandware) 5 Wall St., Burlington, MA]

Everyone should report to Akamai 90 Broadway in the lobby and indicate about the Meetup. Someone form the staff will escort them to the 12th floor.

5:30 - 6:15 - '''Chat, Chew and Brew'''

6:15 - 6:45 '''News, Announcements'''

Chapter and OWASP events and news, audience announcements, questions, application security news(Google and Symantec certs, HTML5, Chrome features, SDLC and Microservices, others?)

6:50 pm '''Random Number Generation - Lava Lamps, Clouds, New Standards and the IoT - Richard Moulds'''

The SANS Institute recently listed "Weak random number generators" as one of the 7 most dangerous security techniques to watch in 2017. But how do you really know how good your random numbers are? Virtualization and IoT make things worse and new standards are a wake-up call. Random numbers are the basis of security for all cryptography, yet they are often taken for granted. Without entropy, crypto is just math.

Learn why random numbers are so hard to generate and validate, compare different technologies in use today across virtualized environments, and discuss operational steps to take the risk out of random numbers and help secure cryptosystems even into the era of quantum computers.

''Speaker'': Richard Moulds, General Manager of Whitewood Security, has spoken at RSA 2017 and at several OWASP chapter events in New York, Chicago and Austin. Richard has over 20 years of experience in the area of cryptography and encryption.

'''November 2, 2016''' - Cambridge [https://www.meetup.com/owaspboston/events/234648485/ Meetup]

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 90 Broadway, Cambridge, MA 02142 (down the street from the usual location)

Everyone should report to Akamai 90 Broadway in the lobby and indicate about the Meetup. Someone form the staff will escort them to the 12th floor.

6:30 '''News, Announcements'''

7:00 '<nowiki/>''Advanced Persistent Legal Threats''' - '''''<nowiki/>'''William Gamble, JD, LLM, EMBA'''

Abstract: Good cyber security can protect IT infrastructure against many attacks. Because of the difficulty in monetizing cyber thefts, the direct loss of a breach can be limited. However, the legal costs, both from government agencies and plaintiffs, can be far greater. The legal landscape, both in the US and internationally is changing as fast if not faster than the technology.

Bio: I am a lawyer and a member of the Florida Bar.I used to practice tax, securities and banking law. I have written three books and spoken around the world on the economic efficiency of legal and regulatory infrastructures specifically in emerging markets like China. Over the past two years, I have immersed myself in cyber security. I now hold the CompTIA A+, Network+, and Security+. I will take the CASP next month. Besides keeping up with the regulations, I am studying incident response and auditing. I am also working toward my health care law certification. My hero is Dr. Johannes Ullrich.

'''September 28, 2016''' - Burlington - [http://www.meetup.com/owaspboston/events/233921522/ Meetup]

Location: [https://www.google.com/maps/place/5+Wall+St,+Burlington,+MA+01803/@42.4877956,-71.1904085,17z/data=!3m1!4b1!4m5!3m4!1s0x89e3758106c4cb55:0xc155e97a6d34883e!8m2!3d42.4877956!4d-71.1882198?hl=en Demandware] at 5 Wall St., Burlington, MA

6:00 '''News, Announcements'''

6:15 '''OWASP Top 10 #1 - Injection Flaws'''

Jim Weiler will discuss XML External Entity Injection flaws; how it works, how to prevent, code examples.

6:45 '<nowiki/>''From the Frontlines of RASP Adoption''' - '''''<nowiki/>'''Goran Begic, VP of Product, IMMUNIO'''

Runtime Application Self-Protection (RASP) is one of the newest technologies coined by Gartner and it is in early stages of adoption in the industry. It promises dynamic defense and automatic mitigation of vulnerabilities in web applications.

This presentation is a summary of experiences from several dozens of commercial evaluations and early adoptions in production that took place this year and provides some examples of situations and challenges that are not specific to any individual vendor. In this talk Goran will provide an overview of buying criteria and evaluation requirements across different industries and some typical pitfalls that can slow down adoption.

After the introduction and a brief reminder on the technology Goran will invite audience to participate in discussion about organizational requirements for adoption and operationalization of RASP.

Questions for discussion:

My application is under attack.
*What actions should I take?
*Who owns the response?
*Which attacks should I respond to and which ones can I ignore?
*How to get started with mitigation provided by technology?
*Does RASP fit with DevOps?
*Does RASP help with remediation?

What this presentation is not: This is not a product pitch in any way. Evaluation criteria, comparison of RASP with IAST and other security technologies, personal experiences and examples discussed in this talk are generally applicable to all RASP solutions.

Key takeaways:

At the end of the presentation you will:
*get a better understanding of requirements for evaluation of RASP and its use cases,
*if you can pull a successful evaluation alone, or if you will need participation of other groups / teams
*learn about critical criteria for success of RASP in production
*how this criteria different relative to appsec testing tools.

'''September 7, 2016''' - Cambridge - [http://www.meetup.com/owaspboston/events/229223967/ Meetup]

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 150 Broadway, Cambridge, MA 02142 (aka 8 Cambridge Center)

6:30 '''News, OWASP tools, documents review'''

7:00 '''Docker Containers and Application Security''' - '''Tsvi Korren'''

Docker containers are transforming the way applications are developed and deployed. Closely tied to DevOps and Continuous Delivery, containers introduce both risks and opportunities to security management in Web applications. This talk will introduce the basic concepts of containers, how companies use them today and how to support this technology while elevating the security posture of your application stacks.

Tsvi Korren, CISSP, has been an enterprise IT professional for 20 years with background in business process consulting in large organizations. Most recently at CA Technologies, he worked across verticals in government, retail, financial institutions and healthcare to implement compliance and security processes, from Identity and Access to Host and Server Controls. Tsvi is currently the director of technical services at Aqua, concentrating on building bridges between DevOps and Security.

'''June 8, 2016''' - Burlington - [http://www.meetup.com/owaspboston/events/230842887/ Meetup]

Location: [https://www.google.com/maps/place/5+Wall+St,+Burlington,+MA+01803/@42.4877956,-71.1904085,17z/data=!3m1!4b1!4m5!3m4!1s0x89e3758106c4cb55:0xc155e97a6d34883e!8m2!3d42.4877956!4d-71.1882198?hl=en Demandware] at 5 Wall St., Burlington, MA

6-6:30 '''News, announcements, job postings, etc. '''

6:30-7 '''Introduction to SQL Injection - Jim Weiler'''

7:00 '''Computer Science Curricula’s Failure - What Should We Do Now?''' - '''Ming Chow & Roy Wattanasin'''

We are still facing the same security vulnerabilities from over a decade ago. The problems are not going away anytime soon and a reason is because Computer Science curricula are still churning out students who are not even exposed to security. This talk will address the lack of emphasis on information security in Computer Science curricula, how CS curricula have an obligation, how to gradually fix the problem by integrating security into many Computer Science undergraduate and graduate classes, and success stories from students. This talk will also discuss what Tufts and Brandeis are currently working on to further address the security education problem by creating a joint cyber security and policy program that spans multiple departments. Additional points and feedback from the audience are encouraged to help with the issue. All are encourage to attend to submit your feedback to help!

Presenters:

Ming Chow - @0xmchow

Ming Chow is a Senior Lecturer at the Tufts University Department of Computer Science. His areas of work are in web and mobile engineering and web security. He was a web application developer for ten years at Harvard University. Ming has spoken at numerous organizations and conferences including the High Technology Crime Investigation Association - New England Chapter (HTCIA-NE), the Massachusetts Office of the Attorney General (AGO), John Hancock, OWASP, InfoSec World, DEF CON, Intel, SOURCE Conference, and BSides Boston. He was a mentor for a Proving Ground speaker at BSides Las Vegas in 2014 and 2015.

Roy Wattanasin - @wr0

Roy Wattanasin is an adjunct faculty at Brandeis University in both the Health and Medical Informatics and Information Security graduate programs. He spends most of his time leading, teaching and developing information security programs, finding vulnerabilities, performing incident response and working on many projects. Roy has spoken at many conferences including RSA, ISSA International, Source Conference, Braintank, Cyber Security World, OWASP and the Security BSides conferences. He is also a healthcare information security professional. He was a mentor for a Proving Ground speaker at BSides Las Vegas in 2015.

'''May 4, 2016''' - Cambridge - [http://www.meetup.com/owaspboston/events/229788205/ Meetup]

Location: Slightly different [http://www.akamai.com/html/about/locations.html Akamai] location: 90 Broadway, Cambridge, MA 02142 between Meadhall and the Mariott

6:30 '''News, OWASP tools, documents review'''

7:00 '''The ABCs of Source-Assisted Web Application Penetration Testing With OWASP ZAP''' - '''Dan Cornell'''

There are a number of reasons to use source code to assist in web application penetration testing such as making better use of penetration testers’ time, providing penetration testers with deeper insight into system behavior, and highlighting specific sections of so development teams can remediate vulnerabilities faster. Examples of these are provided using the open source ThreadFix plugin for the OWASP ZAP proxy and dynamic application security testing tool. These show opportunities attendees have to enhance their own penetration tests given access to source code.

This presentation covers the “ABCs” of source code assisted web application penetration testing: covering issues of attack surface enumeration, backdoor identification, and configuration issue discovery. Having access to the source lets an attacker enumerate all of the URLs and parameters an application exposes – essentially its attack surface. Knowing these allows pen testers greater application coverage during testing. In addition, access to source code can help to identify potential backdoors that have been intentionally added to the system. Comparing the results of blind spidering to a full attack surface model can identify items of interest such as hidden admin consoles or secret backdoor parameters. Finally, the presentation examines how access to source code can help identify configuration settings that may have an adverse impact on the security of the deployed application.

Dan Cornell is a globally recognized application security expert, Dan Cornell holds over 15 years of experience architecting, developing and securing web-based software systems. As the Chief Technology Officer and a Principal at Denim Group, Ltd., he leads the technology team to help Fortune 500 companies and government organizations integrate security throughout the development process. He is also the original creator of ThreadFix, Denim Group's industry leading application security program management platform. Cornell was Principal Investigator as Denim Group researched and developed the Hybrid Analysis Mapping (HAM) technology that lies at the heart of ThreadFix, through a Small Business Innovation Research (SBIR) contract with the Department of Homeland Security's Science and Technology Directorate.

More information at: http://www.denimgroup.com/about_team_dan.html

'''April 6, 2016''' - Cambridge - [http://www.meetup.com/owaspboston/events/229223967/ Meetup]

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 150 Broadway, Cambridge, MA 02142 (aka 8 Cambridge Center)

6:30 '''News, OWASP tools, documents review'''

7:00 '''Runtime Application Self-Protection (RASP) Tools''' - '''Kunal Anand'''

This talk will highlight the latest in AppSec and dive into a different kind of solution called Runtime Application Self-Protection (RASP). We'll also explore a new methodology called language theoretic security (LANGSEC) and explain how it can outperform existing approaches like pattern matching, regular expressions, etc. This talk will lay the foundation via informal and formal theory how lexers, tokenizers and parsers work. We’ll move onto constructing an open source toolchain to analyzing data and exploring interactive data visualizations. Along the way, we’ll cover performance tradeoffs and discuss the challenges of modern application security.

Kunal Anand is the co-founder and CTO of Prevoty, a runtime application security platform. Prior to that, he was the Director of Technology at the BBC Worldwide, overseeing engineering and operations across the company’s global Digital Entertainment and Gaming initiatives. Kunal also has several years of experience leading security, data and engineering at Gravity, MySpace and NASA’s JetPropulsion Laboratory. His work has been featured in Wired Magazine and Fast Company. Kunal received a B.S. from Babson College.

=== Past Training ===

'''June 12th thru 14th 2017''' - Waltham

==February 21st thru 23d 2018 - Location: Dun and Bradstreet 610 Lincoln Street North Building Waltham, Massachusetts 02451==

8AM to 5PM '''3 Day Developer Edition - Practical Web Application Penetration Testing (PWAPT)'''

<p>The Developer Edition contains the same content as the original PWAPT course (Standard Edition), but adds a full day of code remediation lecture and exercises. The code remediation content includes discussions on the proper techniques for mitigating vulnerabilities, and exercises where the instructor and students will modify the application's source code to implement mitigating controls and test them for effectiveness. </p>

<p>This course provides customized training on the latest open source tools and manual techniques for performing end-to-end web application penetration testing engagements. After a quick overview of the penetration testing methodology, the instructor will lead students through the process of testing and exploiting a target web application using the techniques and approaches developed from a career of real world application penetration testing experiences. Students will be introduced to the best open source tools currently available for the specific steps of the methodology, including Burp Suite Pro, and taught how to integrate these tools with manual testing techniques to maximize effectiveness. A major goal of this course is teaching students the glue that brings the tools and techniques together to successfully perform a web application penetration test from beginning to end, an oversight in most web application penetration testing courses.</p>

<p>The majority of the course will be spent performing an instructor led, hands-on web application penetration test against a target application built specifically for this class using a modern technology stack (Python Flask) and including real vulnerabilities as encountered in the wild. No old-school vanilla PHP stuff here folks. Students won’t be given overly simplistic steps to execute independently. Rather, at each stage of the test, the instructor will present the goals that each testing task is to accomplish and perform the penetration test in front of the class while students do it on their own machine. Primary emphasis of these instructor led exercises will be placed on how to integrate the tools with manual testing procedures to improve the overall work flow. This experience will help students gain the confidence and knowledge necessary to perform web application penetration tests as an application security professional.</p>

<p>PWAPT is a PortSwigger preferred [https://portswigger.net/training Burp Suite Training] course. PWAPT students will learn basic and advanced usage techniques for Burp Suite Pro, as well as discover obscure functionality hidden within the vast capabilities of the tool. Students will also receive a 2 week trial license for Burp Suite Pro to use during the course.</p>

<h4 id="outline">Outline</h4>

<p>Day 1:</p>

<ul>
<li>Methodology</li>
<li>Reconnaissance</li>
<li>Mapping</li>
<li>Automated Discovery</li>
<li>Manual Discovery</li>
</ul>

<p>Day 2:</p>

<ul>
<li>Manual Discovery (cont.)</li>
<li>Exploitation</li>
<li>Web Services</li>
</ul>

<p>Day 3: (Developer Edition only)</p>
<ul>
<li>Remediation</li>
</ul>

<h4 id="technical-requirements">Technical Requirements</h4>

<ul>
<li>Laptop with at least two (2) USB ports.</li>
<li>Latest VMware Player, VMware Workstation, or VWware Fusion installed. Other virtualization software such as Parallels or VirtualBox will probably work if the attendee is familiar with its functionality. However, VMware Player should be prepared as a backup.</li>
<li>Ability to disable all security software on their laptop such as Antivirus and/or firewalls (Administrator).</li>
<li>At least twenty (20) GB of hard drive space.</li>
<li>At least four (4) GB of RAM.</li>
</ul>

Tim (lanmaster53) Tomes

Christian, father, husband, veteran, code slinger, aspiring difference-maker and hacking enthusiast.

== Training in ''Tactical DevSecOps: Web Application Testing and Monitoring''==

Sign-Up: http://tinyurl.com/OWASPDevSecOps

Cost:
* $900 for Non Members
* $850 for OWASP Members
* Some US Active Military, Law Enforcement & US Veteran seats are being held aside for FREE entry per the enormous generosity of the trainer! Please be prepared to send us verification of status.
Contact us at boston[at]owasp[dot]org

When: Monday, June 12, 2017 8:00 AM to Wednesday, June 14th, 2017, 4:30 PM ET

Location: 610 lincoln street (north) Waltham, MA 02145

Instructor: [https://www.secureideas.com/about-me.php?bio=kevin Kevin "Professionally Evil" Johnson], who has taught at SANS, and presented at BlackHat & DerbyCon

'''January 25th thru 27th 2017''' - Waltham

Location: Constant Contact [https://www.google.com/maps/place/Constant+Contact/@42.4185837,-71.2586063,15z/data=!4m5!3m4!1s0x0:0xbcaab68dd299cf76!8m2!3d42.4185837!4d-71.2586063 Map] location: 1601 Trapelo Rd, Waltham, MA 02451 - the building on the right furthest away from Trapelo Road

8AM to 5PM '''3 Day Developer Edition - Practical Web Application Penetration Testing (PWAPT)'''

<p>The Developer Edition contains the same content as the original PWAPT course (Standard Edition), but adds a full day of code remediation lecture and exercises. The code remediation content includes discussions on the proper techniques for mitigating vulnerabilities, and exercises where the instructor and students will modify the application's source code to implement mitigating controls and test them for effectiveness. </p>

<p>This course provides customized training on the latest open source tools and manual techniques for performing end-to-end web application penetration testing engagements. After a quick overview of the penetration testing methodology, the instructor will lead students through the process of testing and exploiting a target web application using the techniques and approaches developed from a career of real world application penetration testing experiences. Students will be introduced to the best open source tools currently available for the specific steps of the methodology, including Burp Suite Pro, and taught how to integrate these tools with manual testing techniques to maximize effectiveness. A major goal of this course is teaching students the glue that brings the tools and techniques together to successfully perform a web application penetration test from beginning to end, an oversight in most web application penetration testing courses.</p>

<p>The majority of the course will be spent performing an instructor led, hands-on web application penetration test against a target application built specifically for this class using a modern technology stack (Python Flask) and including real vulnerabilities as encountered in the wild. No old-school vanilla PHP stuff here folks. Students won’t be given overly simplistic steps to execute independently. Rather, at each stage of the test, the instructor will present the goals that each testing task is to accomplish and perform the penetration test in front of the class while students do it on their own machine. Primary emphasis of these instructor led exercises will be placed on how to integrate the tools with manual testing procedures to improve the overall work flow. This experience will help students gain the confidence and knowledge necessary to perform web application penetration tests as an application security professional.</p>

<p>PWAPT is a PortSwigger preferred [https://portswigger.net/training Burp Suite Training] course. PWAPT students will learn basic and advanced usage techniques for Burp Suite Pro, as well as discover obscure functionality hidden within the vast capabilities of the tool. Students will also receive a 2 week trial license for Burp Suite Pro to use during the course.</p>

<h4 id="outline_2">Outline</h4>

<p>Day 1:</p>

<ul>
<li>Methodology</li>
<li>Reconnaissance</li>
<li>Mapping</li>
<li>Automated Discovery</li>
<li>Manual Discovery</li>
</ul>

<p>Day 2:</p>

<ul>
<li>Manual Discovery (cont.)</li>
<li>Exploitation</li>
<li>Web Services</li>
</ul>

<p>Day 3: (Developer Edition only)</p>
<ul>
<li>Remediation</li>
</ul>

<h4 id="technical-requirements_2">Technical Requirements</h4>

<ul>
<li>Laptop with at least two (2) USB ports.</li>
<li>Latest VMware Player, VMware Workstation, or VWware Fusion installed. Other virtualization software such as Parallels or VirtualBox will probably work if the attendee is familiar with its functionality. However, VMware Player should be prepared as a backup.</li>
<li>Ability to disable all security software on their laptop such as Antivirus and/or firewalls (Administrator).</li>
<li>At least twenty (20) GB of hard drive space.</li>
<li>At least four (4) GB of RAM.</li>
</ul>

Tim (lanmaster53) Tomes

Christian, father, husband, veteran, code slinger, aspiring difference-maker and hacking enthusiast.

'''July 18th & 19th 2016''' - Waltham

Location: Constant Contact [https://www.google.com/maps/place/Constant+Contact/@42.4185837,-71.2586063,15z/data=!4m5!3m4!1s0x0:0xbcaab68dd299cf76!8m2!3d42.4185837!4d-71.2586063 Map] location: 1601 Trapelo Rd, Waltham, MA 02451

8AM to 5PM '''Practical Web Application Penetration Testing - PWAPT'''

<p>This course provides customized training on the latest open source tools and manual techniques for performing end-to-end web application penetration testing engagements. After a quick overview of the penetration testing methodology, the instructor will lead students through the process of testing and exploiting a target web application using the techniques and approaches developed from a career of real world application penetration testing experiences. Students will be introduced to the best open source tools currently available for the specific steps of the methodology, including Burp Suite Pro, and taught how to integrate these tools with manual testing techniques to maximize effectiveness. A major goal of this course is teaching students the glue that brings the tools and techniques together to successfully perform a web application penetration test from beginning to end, an oversight in most web application penetration testing courses.</p>

<p>The majority of the course will be spent performing an instructor led, hands-on web application penetration test against a target application built specifically for this class using a modern technology stack (Python Flask) and including real vulnerabilities as encountered in the wild. No old-school vanilla PHP stuff here folks. Students won’t be given overly simplistic steps to execute independently. Rather, at each stage of the test, the instructor will present the goals that each testing task is to accomplish and perform the penetration test in front of the class while students do it on their own machine. Primary emphasis of these instructor led exercises will be placed on how to integrate the tools with manual testing procedures to improve the overall work flow. This experience will help students gain the confidence and knowledge necessary to perform web application penetration tests as an application security professional.</p>

<p>PWAPT is a PortSwigger preferred [https://portswigger.net/training Burp Suite Training] course. PWAPT students will learn basic and advanced usage techniques for Burp Suite Pro, as well as discover obscure functionality hidden within the vast capabilities of the tool. Students will also receive a 2 week trial license for Burp Suite Pro to use during the course.</p>

<h4 id="outline_3">Outline</h4>

<p>Day 1:</p>

<ul>
<li>Methodology</li>
<li>Reconnaissance</li>
<li>Mapping</li>
<li>Automated Discovery</li>
<li>Manual Discovery</li>
</ul>

<p>Day 2:</p>

<ul>
<li>Manual Discovery (cont.)</li>
<li>Exploitation</li>
<li>Web Services</li>
</ul>

<h4 id="technical-requirements_3">Technical Requirements</h4>

<ul>
<li>Laptop with at least two (2) USB ports.</li>
<li>Latest VMware Player, VMware Workstation, or VWware Fusion installed. Other virtualization software such as Parallels or VirtualBox will probably work if the attendee is familiar with its functionality. However, VMware Player should be prepared as a backup.</li>
<li>Ability to disable all security software on their laptop such as Antivirus and/or firewalls (Administrator).</li>
<li>At least twenty (20) GB of hard drive space.</li>
<li>At least four (4) GB of RAM.</li>
</ul>

Tim (lanmaster53) Tomes

Christian, father, husband, veteran, code slinger, aspiring difference-maker and hacking enthusiast.

'''March 16, 2016''' - Burlington - [http://www.meetup.com/owaspboston/events/229156529/ Meetup]

Location: Demandware, Burlington.

6:00 '''News, OWASP tools, documents review'''

6:30 '''Software Security by the Numbers''' - '''Chris Eng'''

Deep dive into data we’ve collected about the state of software security in 2016
* Based on scans of 200,000+ applications over an 18-month period
* How different industries and programming languages compare to one another
* Vulnerability remediation habits and patterns
* Three characteristics of a successful AppSec program

Chris Eng is vice president of research at Veracode. In this role, he leads the team responsible for integrating security expertise into all aspects of Veracode’s technology. Throughout his career, he has led projects breaking, building, and defending web applications and commercial software for some of the world’s largest companies. Chris is a frequent speaker at premier industry conferences, where he has presented on a diverse range of topics, including cryptographic attacks, agile security, mobile application security, and security metrics. He has been interviewed by Bloomberg, Fox Business, CBS, and other media outlets worldwide.

'''January 26, 2016''' - Waltham - [http://www.meetup.com/owaspboston/events/228202040/ Meetup]

Location: Constant Contact, Waltham. Trapelo Rd. exit from Rt. 128, toward Lincoln. The parking lot entrance is on the right, at the first traffic light. Drive around to the front of the office complex, facing the highway. Enter under the clock tower. Park in the front of the building and enter in the main building lobby, continue down the hallway and you will see the innovation center, enter in the large glass doors.

7:00 '''News, OWASP tools, documents review'''

7:20 '''What Security Testing Tools Miss'''

Black Duck Software presents - Static analysis, dynamic analysis, and other testing tools are all essential weapons against adversaries. But for the 80%+ of companies worldwide that use open source software in their application development these tools are ineffective in identifying and mitigating open source security risks . This presentation will cover:

The value of static and dynamic tools, and where they best fit in the Secure Development Lifecycle

Why these tools are not useful in identifying known vulnerabilities in open source components

Controls development and security professionals can deploy to select, detect, manage and monitor open source for existing and newly disclosed vulnerabilities

Food will be provided by Constant Contact.

'''November 2015''' - Cambridge - [http://www.meetup.com/owaspboston/events/226394218/ Meetup]

When: Wednesday, November 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 150 Broadway
Cambridge, MA 02142 (aka 8 Cambridge Center)

6:30 '''News, views, announcements, conversation'''

7:00 '''Interactive Discussions (Come and ask your questions!)'''

Attendee interaction is always mentioned as a high value at meetings and was great at the MetroWest meetings, so we're doing that at Akamai this month. Some discussion starters so far: SSL certificate impacts from CA/Browser alliance decisions and SHA1 weakness; mutual (client) SSL, javascript client and server side; what the heck is threat intelligence, dev ops and faster secure SDLC.

'''July 2015''' - Metrowest

When: Wednesday, July 20, 7:00 pm

Location: Constant Contact, Innovation Center, Reservoir Place, 1601 Trapelo Road, Waltham, MA 02451

7:00 '''News, views, announcements, conversation'''

7:30 '''Access in Maliceland - Risk Based Access Control''' - '''Gunnar Peterson'''

John Lambert observed attackers win because while defenders think in lists, attackers think in graphs. Access control systems divide the system a priori into secure and insecure states. But that’s only worth the paper its printed on. A Attackers see the system as it is, for attackers, the access control scheme is the beginning of the game not the end. Determined attackers seek out access control models and then find holes that they can leverage. Access control systems that purport to protect the system are built on assumptions from which reality diverges. Application security needs a new approach to access control- adding feedback loops for risk based decisions, fine-grained, dynamic access control.

Security is a business with a very long list of issues and requirements. The spreadsheets are miles long. This makes it essential to find reusable solution patterns that can address multiple problems.This presentation looks at both medium term improvements and code examples to improve access control decisions and overall security today

Gunnar Peterson ([https://twitter.com/oneraindrop @oneraindrop]) focuses on security architecture consulting and training. Experience includes Associate Editor for IEEE Security & Privacy Journal, a Microsoft MVP for App security, an IANS Research Faculty member, a Securosis Contributing Analyst, and a Visiting Scientist at Carnegie Mellon Software Engineering Institute. He maintains a popular information security blog at http://1raindrop.typepad.com.

'''July 2015''' - Cambridge

When: Wednesday, July 8, 6:30 pm ''NOTE: It's the second Wednesday this month.''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''Interactive Discussions (Come and ask your questions!)'''

'''June 2015'''

When: Wednesday, June 3, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''Put Down the Megaphone: Effective Security Advocacy Without the Shouting''' - '''Darren Meyer'''

10 years’ experience in the InfoSec community--including work with organizations in many verticals, in sizes ranging from startups to Fortune 50 enterprises, leading Application Security teams, building and delivering security instruction to developers, managers, and InfoSec professionals—has taught me the importance of crafting advocacy for different audiences. In this talk, I share my experiences in learning to be an effective advocate with three key audiences: developers, management, and non-technical staff.

Darren is an Application Security advocate and researcher, technology hobbyist, and maker. He loves to learn, teach, nerd out, and inflict terrible puns on people. His background includes logistics, software development, and an assortment of information security roles including leading AppSec programs and professional security instruction targeting developers, managers, and InfoSec professionals.

'''May 2015'''

When: Wednesday, May 6, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''How the crowd is discovering critical vulns missed by traditional methods''' - '''Leif Dreizler'''

State of the art security programs are turning to bug bounties to leverage a vast array of skill-sets and knowledge. Learn why these programs work, when to deploy them, and how you can bring these new application security testing capabilities into your own organization. The speaker will discuss real world examples from bug bounties and focus on cases where business logic flaws and high priority vulnerabilities were found ... even with existing security testing processes in place.

Attendees will learn:

Testing methods deployed by our crowd that help them find bugs the scanners miss

Examples of the high quality of bugs our crowd is finding, including P1'sTrends which vulnerability types are found most often and whyWhat is the ROI on the pay for performance modelWhere does the SDLC merge into crowdsourced testing

Leif Dreizler is a Senior Security Engineer at Bugcrowd, the innovator in crowdsourced security testing for the enterprise. Prior to joining Bugcrowd, Leif was a Senior Application Security Engineer at Redspin, performing application security assessments. During his time at Redspin he also served as the Application Team Lead, liaising with clients at the engineering and sales level. He has also made minor contributions to the Firebug project. Leif attended the University of California, Santa Barbara where he studied Computer Science. Leif recently spoke to the NYC Security Meet-up group.

'''April 2015'''

When: Wednesday, April 1, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

Jim Weiler Will show some actual examples and patterns of SQL Injection attempts

7:00 '''Are You An Imposter? Me too!''' - '''Patrick Laverty'''

Many people in the information security field feel like a fraud, or an imposter. In reality, we often know far more, and are capable of far more than we believe we do. There is so much to know and we constantly hear about the latest groundbreaking research done by others, which makes us feel less important or worthy. Let’s talk about what Imposter Syndrome is, its prevalence, and then we can start to realize just how capable we are and go forward with the confidence in the field.

'''March 2015'''

When: Wednesday, March 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''Prioritizing Web Application Vulnerabilities – A Hacker’s Perspective''' - '''Nick Silver'''

The best application risk models capture not only the technical risk factors, but also the business context in which an asset lives. Traditionally, this is done by auditing application owners on an array of questions in order to properly classify the asset and its data – but that takes time which could be better spent elsewhere. We interviewed dozens of hackers and asked them which vulnerabilities they would look for first depending on the type of attack they wanted to carry out. We’ll walk through several examples of how to use this data as a shortcut means for prioritizing risk without the need for any pesky audit questionnaires.

Nick Silver is a Senior Solutions Architect with WhiteHat Security. He is responsible for translating business requirements into technical ones and assisting businesses in implementing web security programs. Previously, Nick led a team in WhiteHat’s Threat Research Center where they were responsible for testing more than 2,000 of their customers’ websites for vulnerabilities.

'''February 2015'''

When: Wednesday, February 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News review, announcements''' - '''Jim Weiler'''

7:00 '''Incident Response and Web Application Security - Stories from the Trenches''' - '''Fred House and Joe Ceirante'''

Mandiant has conducted numerous incident response engagements throughout its history, including a record number of 200 incidents in 2014. Mandiant consultants Fred House and Joe Ceirante will discuss case studies and trends Mandiant has observed in relation to web application security.

Topics will include the types of threat actors that target web applications, the techniques they use to compromise web applications, and the activities they perform once inside the network. Techniques for detecting and mitigating web compromises will also be reviewed. All content will be derived from the real-world compromises that Mandiant has investigated.

'''January 2015'''

When: Wednesday, January 7, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News review, risk analysis of Poodle''' - '''Jim Weiler'''

7:00 '''How a Hacker Views Your Web Site''' - '''Patrick Laverty'''

''The most popular presentation of BASC 2014''

As defenders, we have to be right 100% of the time where an attacker only needs to be right once. The attack surface of a modern web site is incredibly large and we need to be aware of all of it. Additionally, individual attacks may not always be effective but sometimes using them together can gain the desired effect. In this talk, we’ll take a look at the whole attack surface for a typical web site and the various ways that an attacker will use to compromise a site.

'''December 2014'''

When: Wednesday, December 3, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News and Views You Can Use and Abuse''' - '''Jim Weiler'''

* Some thoughts and analysis on some current app security news and other stuff
* Adobe password breach
* Reducing Web Application Firewall SQL injection false positives

7:15 '''Swift and Security''' - '''Ming Chow'''

Apple is pushing its new programming language Swift for iOS development and for many good reasons. This talk will discuss what the language has right in terms of security, the old and new security pitfalls, and what developers need to be aware of moving forward with using the new language. The fact to the matter is, iOS isn't going away, iOS developers will need to learn and use Swift, and there will be a big rush of Swift-based apps: we might as well learn how to do it right the first time around.

Ming Chow is an Instructor at the Department of Computer Science, Tufts University. Ten years of web development experience.
Specialties: Web and Mobile Development, Web and Mobile Security

'''July 2014'''

Topics: '''Grails Security''' and '''Validating Cross-Site Scripting Vulns with xssValidator'''

Presenters: '''Cyrus Malekpour''' and '''John Poulin'''

When: Tuesday, July 8, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic 1: ''Grails Security''

Grails is a framework developed for Groovy in the vein of Rails for Ruby. It provides a lot of features for web app security, but does it do enough? What might you need to implement yourself, and what might be provided? This presentation will discuss tips on securing Grails applications, including tools that the framework provides by default for security. It'll also discuss several shortcomings in the current toolset, and how you can avoid them.

Cyrus Malekpour (@cmalekpour) is currently interning at nVisium, working on web app development and security. He's currently an undergraduate student at the University of Virginia, where he's studying computer science with an emphasis on security and backend development.

Topic 2: ''Validating Cross-Site Scripting Vulns with xssValidator''

xssValidator is a tool developed to automate the testing and validation of Cross-Site Scripting (xss) vulnerabilities within web applications. Automated scanners tend to report large amounts of false-positives, and as consultants we're forced spending our time trying to verify these findings. xssValidator leverages scriptable web-browsers such as PhantomJS and Slimer.js to automatically validate these findings.

John Poulin is an application security consultant for nVisium who specializes in web application security. He worked previously as a web developer and software engineer that focused on building multi-tier web applications. When he's not hacking on web apps, John spends his time building tools to help him hack on web apps! You can find him on twitter: @forced_request and on myspace: REDACTED.

'''June 2014'''

Topic: '''Training: SQL Injection and the OWASP Zed Attack Proxy (ZAP)'''

Presenters: '''Rob Cheyne and Jim Weiler'''

When: Wednesday, June 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 - general networking, news discussion, announcements.

7:00 - main presentations

The June 4th meeting will be the second in our series of 2014 training meetings. Rob Cheyne will continue explaining and exploring SQL Injection by conducting an actual injection attack.

This will be a demo-based discussion to get into the mindset of an attacker, and show how an attacker goes after a site. Demo will include:

* BurpProxy demo
* Common authentication flaws
* SQL Injection Demo that shows the process and how it builds to a full compromise

'''Rob Cheyne''' is currently CEO of Big Brain Security. In addition to security consulting for Fortune 500 customers, he was the author of LC4, a version of the award-winning L0phtCrack password auditing tool, and he also worked on the code scanning technology that was eventually spun off as Veracode. Rob was at @stake from the very first customer all the way through to the $50M acquisition by Symantec.

'''Jim Weiler''' will introduce the OWASP Zed Attack Proxy (ZAP). This is a very powerful free OWASP intercepting proxy that lets you see, analyze, change, replay etc. every browser request and response, analyze your session, scan and attack web sites, save the results and run reports. We can't cover all the functionality but we'll show some practical tips and techniques.

Pizza, salad and soda courtesy of Akamai

'''March 2014'''

Topic: '''Training: SQL Injection, WebGoat, Cross Site Request Forgery'''
Presenter: '''Benjamin Lerner'''
When: Wednesday, March 5, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

There will be three training sessions:

One will be on SQL Injection - intro, detection, prevention, scanning and false positives. This is the most serious web application vulnerability.

The second will be on OWASP WebGoat. WebGoat is a deliberately insecure web application maintained by OWASP designed to teach web application security lessons. You can install and practice with WebGoat in either J2EE or in ASP.NET. In each lesson, users must demonstrate their understanding of a security issue by exploiting a real vulnerability in the WebGoat applications. There are hints and 39 different lesson plans on various vulnerabilities and technologies. We won't cover all of them of course!

The third will be on Cross Site Request Forgery - not a hack really, it's just the way the web works. But it causes apps to do legitimate things that you didn't ask them to do.

Pizza and drinks provided by Akamai.

'''January 2014'''

When: Wednesday, January 8, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic: '''JavaScript Verification: From Browsers to Pages'''

Modern web browsers implement a "private browsing" mode that is intended to leave behind no traces of a user's browsing activity on their computer. This feature is in direct tension with support for *extensions*, which let users add third-party functionality into their browser. I will discuss the scope of this problem, present our approach to verifying extensions' compliance with private browsing mode, and sketch our findings on several real, third-party extensions. I will then briefly describe the toolkit underlying our approach, and end with a sketch of a newer project, adapting this approach to the very different-seeming problem of statically catching errors when using the jQuery library.

Presenter: '''Benjamin Lerner'''

Benjamin Lerner has just completed a post-doctoral research position in the PLT group at Brown University, and is now a lecturer at Northeastern University. His research examines the challenges of analyzing client-side web programming, from the behavior of web pages down through the semantics of the browser. He received a PhD in Computer Science from the University of Washington in 2011, building a platform to analyze conflicts between browser extensions, and a B.S. in Computer Science and Mathematics from Yale University.

'''November 2013'''

When: Wednesday, November 6, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic: '''Attacking iOS Applications'''

Slides: [http://www.slideshare.net/kfosaaen/i-os-gcandpb On slideshare]

This presentation will cover the basics of attacking iOS applications (and their back ends) using a web proxy to intercept, modify, and repeat HTTP/HTTPS requests. (The proxy used during research was Burp; however, any HTTP intercepting proxy such as OWASP ZAP could be used) From setting up the proxy to pulling data from the backend systems, this talk will be a great primer for anyone interested in testing iOS applications at the HTTP protocol level. There will be a short (2 minute) primer on setting up the intercepting proxy, followed by three practical examples showing how to intercept data headed to the phone, how to modify data heading to the application server, and how to pull extra data from application servers to further an attack. All of these examples will focus on native iOS apps (Game Center and Passbook) and/or functionality (Passbook Passes).

Presenter: '''Karl Fosaaen'''

Karl is a senior security consultant at NetSPI. This role has allowed Karl to work in a variety of industries, including financial services, health care, and hardware manufacturing. Karl specializes in network and web application penetration testing. In his spare time, Karl helps out as an OPER at THOTCON and a swag goon at DEF CON.

'''October 2013'''

When: Wednesday, October 2, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic: '''Abusing NoSQL Databases'''

The days of selecting from a few SQL database options for an application are over. There is now a plethora of NoSQL database options to choose from: some are better than others for certain jobs. There are good reasons why developers are choosing them over traditional SQL databases including performance, scalabiltiy, and ease-of-use. Unfortunately like for many hot techologies, security is largely an afterthought in NoSQL databases. This short but concise presentation will illustrate how poor the quality of security in many NoSQL database systems is. This presentation will not be confined to one particular NoSQL database system. Two sets of security issues will be discussed: those that affect all NoSQL database systems such as defaults, authentication, encryption; and those that affect specific NoSQL database systems such as MongoDB and CouchDB. The ideas that we now have a complicated heterogeneous problem and that defense-in-depth is even more necessary will be stressed. There is a common misconception that SQL injection attacks are eliminated by using a NoSQL database system. While specifically SQL injection is largely eliminated, injection attack vectors have increased thanks to JavaScript and the flexibility of NoSQL databases. This presentation will present and demo new classes of injection attacks. Attendees should be familiar with JavaScript and JSON.

Presenter: '''Ming Chow'''

Ming Chow (@tufts_cs_mchow) is a Lecturer at the Tufts University Department of Computer Science. His areas of work are in web and mobile engineering and web security. He teaches courses largely in the undergraduate curriculum including the second course in the major sequence, Web Programming, Music Apps on the iPad, and Introduction to Computer Security. He was also a web application developer for ten years at Harvard University. Ming has spoken at numerous organizations and conferences including the High Technology Crime Investigation Association - New England Chapter (HTCIA-NE), the Massachusetts Office of the Attorney General (AGO), John Hancock, OWASP, InfoSec World (2011 and 2012), DEF CON 19 (2011), the Design Automation Conference (2011), Intel, and the SOURCE Conference (Boston 2013). Ming's projects in information security include building numerous CTF challenges, Internet investigations, HTML5 and JavaScript security, and Android forensics.

'''September 2013 - Joint Meeting with [http://www.meetup.com/Boston-cloud-services/ Boston Cloud Services]'''

When: Tuesday, September 10, 6 pm

Location: Microsoft NERD Center ''(not our usual location)''

'''Note: This is a joint meeting. Please register at [http://www.meetup.com/Boston-cloud-services/ the Boston Cloud Services meetup page] if you plan to attend.'''

There will be two presentations at this meeting:

Topic: '''People Centric Security (PCS)'''

Presenter: '''Nick Stamos'''

People Centric Security (PCS) is a new security model, presented as part of Gartner's Maverick Research 2 year ago. PCS is well suited for Cloud Business/Consumer services such as Dropbox, Google Drive, SkyDrive, etc. PCS enables users to have what they desire, and provides enterprises what they require for data governance and compliance. Nick Stamos co-founded his fourth company, nCrypted Cloud in July of 2012. His past startups include Verdasys, Phase Forward (IPO FY2004, $685M Oracle Acquisition 2010), and Amulet. He studied at Tufts University where he received a BSEE and MSEE.

Topic: '''SSL Certs'''

Presenter: '''Jim Weiler'''

Practical experiences with issuing and risk assessing SSL certs for enterprise applications on a cloud provider: who creates the CSR, how do you protect the private key on the cloud server, certs on cloud provider managed load balancers vrs 3rd party managed app servers, roles and responsibilities of cloud IT, 3rd party developer IT, enterprise IT and service providers. Jim Weiler is Application Security Architect at Starwoods Hotels and the Chapter Leader of OWASP Boston.

'''July 2013 - Doubleheader!'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, July 10, 6:30 pm

Topic: '''RailsGoat'''

Presented by: '''Ken Johnson'''

Abstract: While working to secure rails applications in a truly Agile development environment, it became clear that the Rails and Ruby ecosystem needed attention from the security community in the form of free and open training, and the events that have transpired within the last few months have only reinforced that belief. [http://railsgoat.cktricky.com/ RailsGoat] is an attempt to bring attention to both the problems that most frequently occur in Rails as well as the solutions for remediation. To accomplish this, we've built a vulnerable Rails application that aligns with the OWASP Top 10 and can be used as a training tool for Rails-based development shops.

Topic: '''PhoneGap on Android'''

Presented by: '''Jack Mannino'''

Abstract: PhoneGap is a widely used framework that allows developers to rapidly build cross-platform mobile applications using HTML5, JavaScript, and CSS. Using PhoneGap plugins, developers can call native platform APIs from browser-like applications using JavaScript. This approach introduces vulnerabilities that are not typically as prevalent within native Android applications, warranting a fresh look at the way we view mobile applications. In this presentation, we will take a deep look at the Android implementation of the framework and we will examine the overall attack surface for applications. Real-world examples of vulnerable applications will be demonstrated as well in order to provide context, entertainment, and enjoyment.

About the Speakers:

Ken Johnson is the former Manager of LivingSocial.com's application security team where he built their security program before leaving for his true home as the CTO of nVisium Security, a VA-based application security company. Ken is the primary developer of the Web Exploitation Framework and contributes to other open source application security projects as often as time permits. He has spoken at AppSec DC 2010 and 2012, OWASP NoVA and Phoenix chapters, Northern Virginia Hackers Association (NoVAH) and is a contributor to the Attack Research team.

Jack Mannino is the CEO of nVisium Security, a VA-based application security company. At nVisium, he helps to ensure that large corporations, government agencies, and software startups have the tools they need to build and maintain successful security initiatives. He is an active Android security researcher/tinkerer, and has a keen interest in identifying security issues and trends on a large scale. Jack is a leader and founder of the OWASP Mobile Security Project. He is the lead developer for the OWASP GoatDroid project, and is the chairman of the OWASP Northern Virginia chapter.

'''June 2013'''

Topic: '''We see the future…and it isn’t pretty'''

Presented by: '''Andrea Mulligan, Sr. Director at Veracode'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, June 5, 6:30 pm

In this session Andrea presents research findings from the State of Software Security Report, which offers a before the breach look at security by examining the flaws commonly found in applications of all kinds. She will also examine what the research findings mean for security, predict how these flaws could cause history to repeat itself, and discuss how security pros can help change the future.

'''May 2013'''

Topic: '''Systems Thinking + Web Security'''

Presented by: '''Akamai'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, May 1, 6:30 pm

Akamai will present on ‘Systems Thinking + Web Security’. There will also be an audience review exercise facilitated by the Akamai presenters. This is a great chance to hear some interesting perspectives on web security from Akamai, who handles about one third of all internet traffic.

'''April 2013'''

Topic: '''Go Fast. Be Secure: Effectively Govern the Use of Open Source Components Throughout the SDLC'''

Presented by: '''Sonotype'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, April 3, 6:30 pm

* Open Source Software (OSS) Component supply chain complexities and realities. Open source is constantly changing and knowing the version in your software, as well as the current version history of the component (how do you show an auditor you are using a current version) is important.
* Open Source Consumption Patterns from the Central Repository. Which versions are the most popular can tell you which versions are the most stable, useful, secure etc.
* OWASP Top 10 (A9) - Using Components with Known Vulnerabilities. To decide on the risk of OSS components with vulnerabilities, you need to know the vulnerabilities, their severity and which components they occur in as well as where in the code dependency tree they are.
* OSS Security, Quality and License policies must be woven into the development process. Knowing the number and type of open source licenses in your software can be important to the legal standing of your code and if it conflicts with any corporate standards. The licensing is also important in order to know the restrictions on changing the software.
* OSS Component Policy Examples
* Example Application Compositions Reports
* Example Use cases IDE, CI, repository, production applications
* Discussion

About Sonatype:

Sonatype operates the Central Repository, the industry's primary source for open-source components, housing more than 400,000 components and serving more than five billion requests per year from more than 60,000 organizations. The company has been a pioneer in component-based software development since its founding by Jason van Zyl, the creator of the Apache Maven build management system and the Central Repository.

'''March 2013'''

Topic: '''What is BSIMM?'''

Speaker: '''Nabil Hannan'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Nabil is Director of Vulnerability Assessments and Managing Consultant at Cigital.

The purpose of the BSIMM is to quantify the activities carried out by real software security initiatives. BSIMM is a study of the secure development practices of over 50 organizations, analyzed along the dimensions that were found in the data, not along preconceived ideas of what secure development should be.

BSIMM describes the work of 974 software security group members working with a satellite of 2039 people to secure the software developed by 218,286 developers.

The BSIMM describes 111 activities that any organization can put into practice. The activities are described in twelve practices grouped into four domains. Associated with each activity is an objective.

'''February 2013'''

Topic: '''BroBot'''

Speaker: '''Eric Kobrin, Akamai'''

When: Wednesday, February 6, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Eric Kobrin is a Senior Security Architect in the Infosec organization of Akamai Technologies, the global leader in Cloud-based application acceleration and content delivery. Eric has been involved in Software Architecture for over 15 years, having worked at such companies and IBM, Velocitude and eDiets.com. He has a passion for programming languages, security, and software performance and has worked in all layers of the software stack from hypervisors to complex servers and web applications. Eric's works have been published, presented at international conferences and patented.

His presentation will provide an analysis of the BroBot DDOS attacks, including discussion of:

* Vulnerable system discovery
* Zombie compromise
* Control structure
* Attack traffic
* Mitigation steps

'''January 2013'''

Topic: '''Third-Party Application Analysis: Best Practices and Lessons Learned'''

Speaker: '''Chad Holmes, Veracode'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Chad Holmes will present details of the work Veracode has been doing with their 3rd Party program, discuss the technical and business challenges that have arisen during that time and lead a discussion on what team members can do to help drive adoption of security best practices across their vendor community.

The flow of the presentation is designed to drive discussion within an audience – both from a technical and business perspective with some anecdotal stories. Chad wants this to be an interactive discussion so he’ll have questions and you should bring yours I’ve already sent him some. The order of the presentation is:

· Adoption rates of externally developed software

· The risk within those apps

· Some deeper stats on what “3rd party” really means (total outsourcing/total COTS produced/open source/imported libraries/etc)

· Some raw data about our experiences (to show this is based on a large sample size rather than “Look how awesome Veracode is!”)

· Challenges that will be faced (business, intellectual property, policy, analysis capabilities, etc)

· Best Practices for high rates of adoption

· Lessons Learned and Recommendations

Chad Holmes has over 10 years of software development and application security experience. During his time at Veracode, Chad has lead the redesign and execution of the third-party analysis process to allow for a more streamlined approach while still addressing common ISV intellectual property concerns. In addition to his third-party analysis responsibilities, Chad's previous work as a Security Program Manager has lead to the successful roll out and improvement of multiple corporate application security groups.

'''June 2012'''
Location - Microsoft Waltham (201 Jones Rd., Sixth Floor Waltham, MA)

Speaker '''Will Vandevanter - Rapid 7'''

'''Fingerprinting web applications of all kinds'''

This turbo talk will introduce a new Metasploit module that fingerprints "known" web applications, attempts the default credentials for the application, and runs an associated exploit or authenticated access module if applicable. Some example fingerprints in the database target common enterprise web applications including Microsoft products (Outlook Web Access, Sharepoint), printers (Xerox Document Centre), security cameras, routers, and others.

Will Vandevanter is a senior penetration tester and researcher at Rapid7. His focus interests include web application security and secure code. He has previously spoken at Defcon, SOURCE, BSides LV, and other conferences.

'''May 31 2012'''

Location - Jobspring, Boston. 545 Boylston st.

Speaker - '''Glenn Gramling, Vice President, Cenzic'''

“Cloudy with a Chance of Hack”

Cloud computing is a cost effective and efficient way for enterprises to automate their processes. However organizations need to be aware of the pitfalls of the many cloud solutions out there - one of the main being security. Most cloud applications were built for ease of use and without security necessarily in mind. Companies need to be asking their solution providers about the security measures used in developing the application and get an independent verification to make sure there are no gaping holes. With over 75% of attacks occurring through the Web, any attack through these applications can lead to leakage of confidential information and embarrassment. In this session, we'll give attendees tips and tricks to prepare them for the potential of "stormy weather."

Glenn Gramling is responsible for global sales and business development for Cenzic’s application security.

'''April 11, 2012'''

Location - Microsoft Waltham (201 Jones Rd., Sixth Floor Waltham, MA)

Speaker - '''David Eoff, Senior Product Marketing Manager, HP Enterprise Security'''

David is a Senior Product Marketing Manager, within the Enterprise Security Products division of HP focused on Fortify application security. His 18+ years of background in software and hardware enterprise marketing provides a solid foundation for his marketing of the HP security solutions.

Prior to joining Fortify in 2009 and being acquired by HP, David ran Firewall and IPS marketing for the Security division of Nokia Corporation. In addition, he has held multiple positions in product marketing, product management, channel marketing and sales while working for Oracle, EMC, Legato, BMC Software and several start-ups.

Topic - '''Gray, the New Black: Gray-Box Vulnerability Testing'''

Over the years, two key techniques have emerged as the most effective for finding security vulnerabilities in software: Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST). While DAST and SAST each possess unique strengths, the “Holy Grail” of security testing is thought to be “hybrid” – a technique that combines and correlates the results from both testing methods, maximizing the advantages of each. Until recently, however, a critical element has been missing from first generation hybrid solutions: information about the inner workings and behavior of applications undergoing DAST and SAST analysis.

This presentation will introduce you to the next generation of hybrid security analysis – what it is, how it works, and the benefits it offers. It will also address (and dispel) the claims against hybrid, and leave you with a clear understanding of how the new generation of hybrid will enable organizations to resolve their most critical software security issues faster and more cost-effectively than any other available analysis technology.

'''March 8, 2012, with the Boston Security Meetup group'''

Location - [http://maps.google.com/maps?q=Jobspring+Partners,+Boylston+Street,+Boston,+MA&hl=en&sll=42.362243,-71.081628&sspn=0.019549,0.037594&oq=jobspring&t=v&hq=Jobspring+Partners,&hnear=Boylston+St,+Boston,+Massachusetts&z=17 JobSpring, Boylston St.]

Topic - '''Corporate Espionage for Dummies: The Hidden Threat of Embedded Web Servers'''

Speaker - VP for Security Research at ZScaler, along with other speakers at the security meetup.

Today, everything from kitchen appliances to television sets come with an IP address. Network connectivity for various hardware devices opens up exciting opportunities. Forgot to lower the thermostat before leaving the house? Simply access it online. Need to record a show? Start the DVR with a mobile app. While embedded web servers are now as common as digital displays in hardware devices, sadly, security is not. What if that same convenience exposed photocopied documents online or allowed outsiders to record your telephone conversations? A frightening thought indeed.

Software vendors have been forced to climb the security learning curve. As independent researchers uncovered embarrassing vulnerabilities, vendors had little choice but to plug the holes and revamp development lifecycles to bake security into products. Vendors of embedded web servers have faced minimal scrutiny and as such are at least a decade behind when it comes to security practices. Today, network connected devices are regularly deployed with virtually no security whatsoever.

The risk of insecure embedded web servers has been amplified by insecure networking practices. Every home and small business now runs a wireless network, but it was likely set up by someone with virtually no networking expertise. As such, many devices designed only for LAN access are now unintentionally Internet facing and wide open to attack from anyone, regardless of their location.

Leveraging the power of cloud based services, Zscaler spent several months scanning large portions of the Internet to understand the scope of this threat. Our findings will make any business owner think twice before purchasing a 'wifi enabled' device. We'll share the results of our findings, reveal specific vulnerabilities in a multitude of appliances and discuss how embedded web servers will represent a target rich environment for years to come.

'''December 13, 2011, 6:30, Microsoft NERD, Cambridge, Horace Mann Room'''

'''Jeremiah Grossman – Founder and CTO WhiteHat Security'''

Directions: http://microsoftcambridge.com/About/Directions/tabid/89/Default.aspx

'''September 14 2011'''

'''Dinis Cruz - OWASP O2 Platform'''

The O2 Platform is focused on automating application security knowledge and workflows. It is a library of scriptable objects specifically designed for developers and security consultants to be able to perform quick, effective and thorough source code-driven application security reviews (blackbox + whitebox).

'''September 7 2011'''

'''Adriel Desautels – Differences between Penetration Testing and Vulnerability Scanning'''

'''July 2011'''

'''Anurag Agarwal, the founder of MyAppSecurity'''

'''Session 1 - Managing Risk with Threat Modeling'''
Threat Modeling can help by guiding the Application Development Teams to ensure your Security Policies get properly coded into the Applications at time of Development. By creating pre-approved methods of coding for your development teams, and applying them in a repeatable and scalable process, you can assist your development teams in building a secure application easily and effortlessly.

'''Session 2 - False Positive, False Negative and False Sense of Security'''
This interactive session will talk about the pros and cons of using black box testing tools and discuss their effectiveness in building a mature software security program.

'''Thursday June 2'''

Location - '''Microsoft NERD''' - http://microsoftcambridge.com/About/Directions/tabid/89/Default.aspx

'''Topic - Bringing Sexy Back: Defensive Measures That Actually Work'''

Presenter - Paul Asadoorian, Founder & CEO, PaulDotCom Enterprises

There is a plethora of information available on how to break into systems, steal information, and compromise users. As a penetration tester, I have performed testing on a regular basis that reveals severe security weaknesses in several organizations, and many of my peers have reported on the same. However, once you "own" the network and report on how you accomplished your goals, now what? Sure, we make defensive recommendations, but consistently it has been proven that security can be bypassed. Not enough focus is given to what works defensively. We have a lot of technology at our disposal: firewalls, intrusion detection, log correlation, but it provides little protection from today's threats and is often not implemented effectively. This talk will focus on taking an offensive look at defense. Applying techniques that are simple, yet break the mold of traditional defensive measures. We will explore setting up "traps" for attackers, slowing them down with simple scripts, using honeypots, planting bugs, and most importantly tying these methods to "enterprise security". This talk will also include real-world examples of the techniques in action from a live, heavily attacked site. Topics will include:

*Using wireless “attacks” on the attackers
*Implementing the Metasploit Decloak engine to find the attackers
*Setting traps to detect web application attacks
*Integrating results into your enterprise log management tool

The goal of this talk is to make defense “sexy”…

'''Presenter Bio'''

Paul Asadoorian is currently the "Product Evangelist" for Tenable Network Security, where he showcases vulnerability scanning and management through blogs, podcasts and videos. Paul is also the founder of PaulDotCom, an organization centered around the award winning "PaulDotCom Security Weekly" podcast that brings listeners the latest in security news, vulnerabilities, research and interviews with the security industry's finest. Paul has a background in penetration testing, intrusion detection, and is the co-author of "WRT54G Ultimate Hacking", a book dedicated to hacking Linksys routers.

'''Thursday May 26'''

Location - Microsoft Waltham (201 Jones Rd., Sixth Floor Waltham, MA)

'''Topic - OWASP Top 10 issue #4 – Insecure Direct Object Reference'''

Presenter - Jim Weiler, Sr. Mgr. Information Security, Starwood Hotels and President of OWASP Boston

Jim Weiler will discuss threat models, risks and various remediations of issue #4 in the 2010 OWASP Top 10 – Insecure Direct Object References.

'''Topic - A Web-Application Architecture for Regulatory Compliant Cloud Computing'''

Presenter - Arshad Noor, StrongAuth

The emergence of cloud-computing as an alternative deployment strategy for IT systems presents many opportunities, yet challenges traditional notions of data-security. The fact that data-security regulations are developing teeth, leaves information technology professionals perplexed on how to take advantage of cloud-computing while proving compliance to regulations for protecting sensitive information.

This presentation presents an architecture for building the next generation of web-applications. This architecture allows you to leverage emerging technologies such as cloud-computing, cloud-storage and enterprise key-management (EKM) to derive benefits such as lower costs, faster time-to-market and immense scalability with smaller investments - while proving compliance to PCI-DSS, HIPAA/HITECH and similar data-security regulations.

'''Presenter Bio'''

Arshad Noor is the CTO of StrongAuth, Inc, a Silicon Vally-based company that specializes in enterprise key management. He is the designer and lead-developer of StrongKey, the industry's first open-source Symmetric Key Management System, and the KeyAppliance - the industry's first appliance combining encryption, tokenization, key-management and a cryptographic hardware module at an unprecedented value. He has written many papers and spoken at many forums on the subject of encryption and key-management over the years.

''' CANCELLED '''

'''Topic – Secure Application design and Coding''' -- CANCELLED

Presenter - Josh Abraham, Rapid 7

'''Speaker Bio '''

'''April 2011'''

Ed Adams Security Innovation -- the new OWASP Exams Project and the work being done by the OWASP Academies Working Group

<br>

'''March 2011'''

Josh Abraham, Rapid 7

Owning the world, one mobile app at a time, and web services pen testing.

<br>

'''Febrary 2011'''

Rob Cheyne, CEO of Safelight Security -

Security Leadership series: Delivering a successful security presentation

<br>

'''December 2010'''

Application Architecture Security Assessment - Second session

Rob Cheyne, CEO SafeLight Security Advisors

<br>

'''November 2010'''

Open SAMM – Software Assurance Maturity Model

Shakeel Tufail is the Federal Practice Manager at Fortify, an HP company.

<br>

'''October 2010'''

Rob Cheyne, CEO SafeLight Security Advisors Overview: In this highly interactive two-part workshop, Rob Cheyne of Safelight Security will show you the basics of conducting a real-world architecture & design review. This workshop draws from Safelight's Security Architecture Fundamentals training course, a two-day course frequently used to teach Fortune 500 companies how to look at their system architectures from both the hacker's and the designer’s point of view.

'''July 2010'''

Lightning Talk – Rob Cheyne, CEO Safelight Security Advisors In this installment of the Safelight lightning talks series, Rob will present the basics of a Cross-site Request Forgery (CSRF).

Main Presentation - Drive-by Pharming with MonkeyFist

Joey Peloquin - Director of Application Security, Fishnet Security

'''June 2010'''

Rob Cheyne Lightning Talk - topic to be announced

Main Presentation - Ryan Barnett The Web Hacking Incident Database (WHID) is a Web Application Security Consortium project dedicated to maintaining a list of web applications related security incidents. Ryan Barnett is director of application security research at Breach Security where he leads Breach Security Labs.

'''May 2010'''

Rob Cheyne Lightning Talk - SQL Injection

Vinnie Liu - Data Exposure, New Approaches to Open Source Intelligence Techniques, and Incident Handling

<br>

'''April 2010'''

Dan Hestad Security Innovation Dan will be talking about his experiences with PCI and web applications, and answering questions about do's and don'ts of acceptable PCI practices in web applications.

'''March 2010'''

Zack Lanier - Disclosure Samsara, or "the endless vulnerability disclosure debate"

http://n0where.org/talks/samsara_20100310.html

http://n0where.org/talks/samsara_20100310.pdf (very large PDF)

<br>

'''February 2010'''

Rob Cheyne of Safelight Security Advisors; New Technology, Same Old Vulnerabilities

<br>

'''January 2010 at Microsoft NERD, Cambridge'''

Josh Abraham, Rapid 7 Technologies

'''December 2009'''

Eric Bender, Cenzic

'''November 2009'''

Jim Weiler, Sr. Mgr. Information Security, Starwood Hotels - Web Application Vulnerability Scanners

Mush Hakhinian, Leader, Application Security Practice, IntraLinks - Secure coding with no money down using SONAR: unleashing the power of open-source code analysis tools

<br>

'''October 2009'''

Paul Schofield, Senior Security Engineer, Imperva - From Rivals to BFF: WAF & VA Unite

<br>

'''September 2009 at CORE Technologies, Boston'''

Paul Asadoorian, Pauldotcom.com

Alex Horan, CORE Security

<br>

'''May 2009'''

Joey Peloquin, Fishnet Security, Secure SDLC: The Good, the Bad and the Ugly [http://www.owasp.org/images/4/48/SecureSDLC-GoodBadUgly.pdf presentation pdf]

<br>

'''March 2009'''

Sabha Kazerooni, Security Compass - Exploit Me tools; Framework Level Threat Analysis

[http://www.owasp.org/images/5/5a/Security_Compass_Exploilt_Me.pdf ExploitMe Document]

[http://www.owasp.org/images/e/ef/Security_Compass_Framework-level_Threat_Analysis.pdf Framework Level Threat Analysis document]

Meeting Pizza Sponsor - Arcot

Arcot is a leader in online fraud prevention, strong authentication and eDocument security. Arcot's solutions are easily deployed, low-cost and extremely scalable, allowing organizations to transparently protect their users from fraud without changing user behavior or requiring expensive hardware.

Arcot can be contacted thru Michael Kreppein, michael.kreppein@arcot.com, 617-467-5200

'''December 2008'''

Brian Holyfield, Gothem Digital Science

Tamper Proofing Web Applications http://www.gdssecurity.com/l/b/2008/12/04/

'''June 2008'''

Jeremiah Grossman; Founder and CTO, Whitehat Security

Appetizer - Hacking Intranets from the Outside (Just when you thought your network was safe) Port scanning with JavaScript

Main Topic - Business Logic Flaws: How they put your Websites at Risk

'''March 2008'''

Chris Eng; Senior Director, Security Research, Veracode

Description – Attacking crypto in web applications

'''December 2007'''

Scott Matsumoto; Principal Consultant, Cigital

Description – You Say Tomayto and I Say Tomahto – Talking to Developers about Application Security

[https://www.owasp.org/images/5/5b/BostonOWASP200712-Cigital.pdf Cigital Presentation]

'''November 2007'''

Tom Mulvehill Ounce Labs

Description – Tom will share his knowledge and expertise on implementing security into the software development life cycle. This presentation will cover how to bring practicality into secure software development. Several integration models will be explored as well as solutions for potential obstacles

[https://www.owasp.org/images/f/f8/Ounce_OWASP_07NOV07ppt.zip Ounce presentation]

<br>

'''October 2007'''

George Johnson, Principal Software Engineer EMC; CISSP

An Introduction to Threat Modeling.

<br>

'''September 2007'''

Day of Worldwide OWASP 1 day conferences on the topic "Privacy in the 21st Century"

'''June 2007'''

Tool Talk - Jim Weiler - WebGoat and Crosssite Request Forgeries

Danny Allan; Director, Security Research, Watchfire

Topic: Exploitation of the OWASP Top 10: Attacks and Strategies

'''March 2007'''

Jeremiah Grossman, CTO Whitehat Security: Top 10 Web Application Hacks of 2006

<br>

'''January 2007'''

Dave Low, RSA the Security Division of EMC: encryption case studies

<br>

'''November 2006'''

<br>

'''September 2006'''

Mike Gavin, Forrester Research: Web Application Firewalls

<br>

'''June 2006'''

Imperva - Application and Database Vulnerabilities and Intrusion Prevention

Jim Weiler - Using Paros Proxy Server as a Web Application Vulnerability tool

<br>

'''May 2006'''

<br>

'''April 2006'''

Dennis Hurst; SPI Dynamics: A study of AJAX Hacking

Jim Weiler; OWASP Boston: Using Paros HTTP proxy, part 1. first meeting with all demos, no powerpoints!

<br>

'''March 2006'''

Mateo Meucci; OWASP Italy [http://www.owasp.org/images/8/8c/Anatomy_of_2_Web_App_Testing.zip Anatomy of 2 web attacks]

Tom Stracener; Cenzic Web Application Vulnerabilities

<br>

'''February 2006'''

Ron Ben Natan; Guardium CTO Database Security: Protecting Identity Information at the Source

<br>

'''January 2006'''

David Low, Senior Field Engineer: RSA Practical Encryption

<br>

'''December 2005'''

Paul Galwas, Product Manager: nCipher [http://www.owasp.org/docroot/owasp/misc/OWASP051207.ppt Enigma variations: Key Management controlled]

<br>

'''November 2005'''

Robert Hurlbut, Independent Consultant [http://www.owasp.org/docroot/owasp/misc/OWASP_Hurlbut_ThreatModelingforWebApplicaitons.zip Threat Modeling for web applications]

<br>

'''October 2005'''

Prateek Mishra, Ph.D. Director, Security Standards and Strategy: Oracle Corp Chaiman of the OASIS Security Services (SAML) Technical Committee - [http://www.owasp.org/docroot/owasp/misc/Federation-Introduction-Overview-01.ppt Identity Federation : Prospects and Challenges]

Ryan Shorter, Sr. System Engineer: Netcontinuum - Application Security Gateways

<br>

'''September 2005'''

Dr. Herbert Thompson, Chief Security Strategist: SecurityInnovation - How to Break Software Security

<br>

'''July 2005'''

Mark O'Neill, CTO: Vordel - [http://www.owasp.org/docroot/owasp/misc/MarkOneill.pdf Giving SOAP a REST? A look at the intersection of Web Application Security and Web Services Security]

'''June 2005'''

Arian Evans, National Practice Lead, Senior Security Engineer: Fishnet Security [http://www.owasp.org/conferences/appsec2005dc/schedule.html Overview of Application Security Tools]

<br>

'''May 2005'''

Patrick Hynds, CTO: Critical Sites - [http://www.owasp.org/docroot/owasp/misc/Passwords-Keys_to_the_Kingdom_Dev_V1.ppt Passwords - Keys to the Kingdom]

<br>

'''April 2005'''

Jonathan Levin - [http://www.owasp.org/docroot/owasp/misc/JLevinRandoms.pdf Of Random Numbers]

Jothy Rosenberg, Founder and CTO: Service Integrity - [http://www.owasp.org/docroot/owasp/misc/JothyRWebSvcsSec.ppt Web Services Security]

<br>

'''March 2005'''

Joe Stagner: Microsoft Let's talk about Application Security

<br>

'''Feb 2005'''

Application Security Inc. PowerPoint slides for the [http://www.owasp.org/docroot/owasp/misc/Anatomy+of+an+Attack.ppt Anatomy of a Database Attack.]

== Local Chapter Information ==

To find out more about the Boston chapter, just join the [http://lists.owasp.org/mailman/listinfo/owasp-boston OWASP Boston mailing list].

The chapter shipping/mailing address is:

OWASP Boston <br />
35 Wachusett Dr <br />
Lexington, MA 02421

== Links ==

[http://www.owasp.org/index.php/Reviews_of_security_podcasts Reviews of security podcasts]

[https://www.owasp.org/index.php/2017_BASC_Homepage Boston Application Security Conference 2017]

[[2016 BASC Homepage|Boston Application Security Conference 2016]]

[[2015 BASC Homepage|Boston Application Security Conference 2015]]

[[2014 BASC Homepage|Boston Application Security Conference 2014]]

[[2013 BASC Homepage|Boston Application Security Conference 2013]]

[[2012 BASC Homepage|Boston Application Security Conference 2012]]

[[2011 BASC Homepage|Boston Application Security Conference 2011]]

[[2010 BASC Homepage|Boston Application Security Conference 2010]]

== Boston OWASP Chapter Leaders ==

'''President'''

- [mailto:jim.weiler@owasp.org Jim Weiler] 781 356 0067

'''Board of Directors'''

* [mailto:lindaleigh.aberdale@owasp.org LindaLeigh Aberdale]
* [mailto:mark.arnold@owasp.org Mark Arnold]
* [mailto:tom.conner@owasp.org Tom Conner]
* [mailto:mike.perez@owasp.org Mike Perez]
* [mailto:roy.wattanasin@owasp.org Roy Wattanasin]
* [mailto:pedro.marcano@owasp.org Pedro Marcano]
* [mailto:Mark.Schlepphorst@owasp.org Mark Schlepphorst]
* [mailto:Ori.Zigindere@owasp.org Ori Zigindere]
__NOTOC__

[[Category:Boston]]
[[Category:OWASP_Chapter]]
[[Category:Massachusetts]]

3rd Party Javascript Management Cheat Sheet

2019-02-03T21:55:44Z

Jweiler:

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br />
__TOC__{{TOC hidden}}
= Introduction =

Tags, aka marketing tags, analytics tags etc. are one of two types of HTML elements on a web page. They are either an <image> or a <script> element. The original tags were only image elements that specified a 1 by 1 image, so they were called pixel tags. The term 'pixel' is now used to mean either image or javascript tags. When discussing tags, and someone says a pixel, you may need to determine if that term is used in the general sense meaning both script and image tags, or whether they are referring to an image element and not a script element. The reason for them is to collect data on the web user attributes, actions and browsing context for use by the web page owner in marketing.

A single pixel image element was used because the image source would be the 3rd party tag vendor, so the browser would create a request to the vendor which could include any vendor cookies, that could then be used to track the user, because the referer header in the request would have the web page URL that the user was on.

We are only concerned with script tags in this document.

Third party vendor javascript tags (hereinafter, '''tags''') can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =
The single greatest risk is a compromise of the third party javascript server, and the injection of malicious javascript into the original tag javascript. This has happened in 2018 (see magecart references at the end of this article) and likely earlier.

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for '''tags'''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html></nowiki>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki>
<html>
<head></head>
<body>
...

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or '''tag manager''' site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a '''container''' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

<nowiki>
<html>
<head></head>
<body>
...

<script>(function(w, d, s, l, i){
w[l] = w[l] || [];
w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : '';
j.async=true;
j.src='https://tagmanager.com/tm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>

</body>
</html></nowiki>

=== Security Problems with requesting Tags ===

The previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. One way to manage this risk is with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This is a secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement:

* technical controls such as only allowing the javascript to access the data layer values, no other DOM element
* restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and javascript code

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<nowiki><script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script></nowiki>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because sometimes you can get '''secure''' but '''not working''' 3rd party code when the vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2017-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2017 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki>
<html>
<head></head>
<body>
...

<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html></nowiki>

<nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Virtual iframe Containment ==

This technique creates iFrames that run asynchronously in relation to the main page. It also provides its own containment javascript that automates the dynamic implementation of the protected iFrames based on the marketing tag requirements.

== Vendor Agreements ==

You can have the agreement or request for proposal with the 3rd parties require evidence that they have implemented secure coding and general corporate server access security. But in particular you need to determine the monitoring and control of their source code in order to prevent and detect malicious changes to that javascript.

= MarTechSec =

Marketing Technology Security

This refers to all aspects of reducing the risk from marketing javascript. Controls include

1. Contractual controls for risk reduction; the contracts with any MarTech company should include a requirement to show evidence of code security and code integrity monitoring.

2. Contractual controls for risk transference: the contracts with any MarTech company could include a penalty for serving malicious javascript

3. Technical controls for malicious javascript execution prevention; Virtual Iframes,

4. Technical controls for malicious javascript identification; Subresource Integrity

5. Technical controls including client side javascript malicious behavior in penetration testing requirements

= MarSecOps =
Marketing Security Operations

This refers to the operational requirements to maintain some of the technical controls. This involves possible cooperation and information exchange between the marketing team, the martech provider and the run or operations team to update the information in the page controls (SRI hash change, changes in pages with SRI), the policies in the Virtual iFrames, tag manager configuration, data layer changes etc.

The most complete and preventive controls for any site containing non-trivial marketing tags are -

1. A data layer that calls the marketing server or tag manager APIs , so that only your code executes on your page (inversion of control)

2. Subresource Integrity

2. Virtual frame Containment.

The MarSecOps requirements to implement technical controls at the speed of change that marketing wants or without a significant number of dedicated resources, can make data layer and Subresource Integrity controls impractical.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

https://www.riskiq.com/blog/labs/magecart-ticketmaster-breach/

https://www.clearskysec.com/magecart/

https://www.riskiq.com/blog/labs/magecart-keylogger-injection/

https://www.zdnet.com/article/inbenta-blamed-for-ticketmaster-breach-says-other-sites-not-affected/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br />

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]
|}

3rd Party Javascript Management Cheat Sheet

2019-02-03T21:54:08Z

Jweiler: changed reference to 2013 top 10 to 2017

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br />
__TOC__{{TOC hidden}}
= Introduction =

Tags, aka marketing tags, analytics tags etc. are one of two types of HTML elements on a web page. They are either an <image> or a <script> element. The original tags were only image elements that specified a 1 by 1 image, so they were called pixel tags. The term 'pixel' is now used to mean either image or javascript tags. When discussing tags, and someone says a pixel, you may need to determine if that term is used in the general sense meaning both script and image tags, or whether they are referring to an image element and not a script element. The reason for them is to collect data on the web user attributes, actions and browsing context for use by the web page owner in marketing.

A single pixel image element was used because the image source would be the 3rd party tag vendor, so the browser would create a request to the vendor which could include any vendor cookies, that could then be used to track the user, because the referer header in the request would have the web page URL that the user was on.

We are only concerned with script tags in this document.

Third party vendor javascript tags (hereinafter, '''tags''') can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =
The single greatest risk is a compromise of the third party javascript server, and the injection of malicious javascript into the original tag javascript. This has happened in 2018 (see magecart references at the end of this article) and likely earlier.

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for '''tags'''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html></nowiki>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki>
<html>
<head></head>
<body>
...

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or '''tag manager''' site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a '''container''' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

<nowiki>
<html>
<head></head>
<body>
...

<script>(function(w, d, s, l, i){
w[l] = w[l] || [];
w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : '';
j.async=true;
j.src='https://tagmanager.com/tm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>

</body>
</html></nowiki>

=== Security Problems with requesting Tags ===

The previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. One way to manage this risk is with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This is a secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement:

* technical controls such as only allowing the javascript to access the data layer values, no other DOM element
* restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and javascript code

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<nowiki><script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script></nowiki>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because sometimes you can get '''secure''' but '''not working''' 3rd party code when the vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2017-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki>
<html>
<head></head>
<body>
...

<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html></nowiki>

<nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Virtual iframe Containment ==

This technique creates iFrames that run asynchronously in relation to the main page. It also provides its own containment javascript that automates the dynamic implementation of the protected iFrames based on the marketing tag requirements.

== Vendor Agreements ==

You can have the agreement or request for proposal with the 3rd parties require evidence that they have implemented secure coding and general corporate server access security. But in particular you need to determine the monitoring and control of their source code in order to prevent and detect malicious changes to that javascript.

= MarTechSec =

Marketing Technology Security

This refers to all aspects of reducing the risk from marketing javascript. Controls include

1. Contractual controls for risk reduction; the contracts with any MarTech company should include a requirement to show evidence of code security and code integrity monitoring.

2. Contractual controls for risk transference: the contracts with any MarTech company could include a penalty for serving malicious javascript

3. Technical controls for malicious javascript execution prevention; Virtual Iframes,

4. Technical controls for malicious javascript identification; Subresource Integrity

5. Technical controls including client side javascript malicious behavior in penetration testing requirements

= MarSecOps =
Marketing Security Operations

This refers to the operational requirements to maintain some of the technical controls. This involves possible cooperation and information exchange between the marketing team, the martech provider and the run or operations team to update the information in the page controls (SRI hash change, changes in pages with SRI), the policies in the Virtual iFrames, tag manager configuration, data layer changes etc.

The most complete and preventive controls for any site containing non-trivial marketing tags are -

1. A data layer that calls the marketing server or tag manager APIs , so that only your code executes on your page (inversion of control)

2. Subresource Integrity

2. Virtual frame Containment.

The MarSecOps requirements to implement technical controls at the speed of change that marketing wants or without a significant number of dedicated resources, can make data layer and Subresource Integrity controls impractical.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

https://www.riskiq.com/blog/labs/magecart-ticketmaster-breach/

https://www.clearskysec.com/magecart/

https://www.riskiq.com/blog/labs/magecart-keylogger-injection/

https://www.zdnet.com/article/inbenta-blamed-for-ticketmaster-breach-says-other-sites-not-affected/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br />

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]
|}

3rd Party Javascript Management Cheat Sheet

2019-02-03T21:50:42Z

Jweiler: better description of tag definition and use of term 'pixel', in first paragraph.

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br />
__TOC__{{TOC hidden}}
= Introduction =

Tags, aka marketing tags, analytics tags etc. are one of two types of HTML elements on a web page. They are either an <image> or a <script> element. The original tags were only image elements that specified a 1 by 1 image, so they were called pixel tags. The term 'pixel' is now used to mean either image or javascript tags. When discussing tags, and someone says a pixel, you may need to determine if that term is used in the general sense meaning both script and image tags, or whether they are referring to an image element and not a script element. The reason for them is to collect data on the web user attributes, actions and browsing context for use by the web page owner in marketing.

A single pixel image element was used because the image source would be the 3rd party tag vendor, so the browser would create a request to the vendor which could include any vendor cookies, that could then be used to track the user, because the referer header in the request would have the web page URL that the user was on.

We are only concerned with script tags in this document.

Third party vendor javascript tags (hereinafter, '''tags''') can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =
The single greatest risk is a compromise of the third party javascript server, and the injection of malicious javascript into the original tag javascript. This has happened in 2018 (see magecart references at the end of this article) and likely earlier.

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for '''tags'''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html></nowiki>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki>
<html>
<head></head>
<body>
...

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or '''tag manager''' site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a '''container''' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

<nowiki>
<html>
<head></head>
<body>
...

<script>(function(w, d, s, l, i){
w[l] = w[l] || [];
w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : '';
j.async=true;
j.src='https://tagmanager.com/tm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>

</body>
</html></nowiki>

=== Security Problems with requesting Tags ===

The previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. One way to manage this risk is with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This is a secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement:

* technical controls such as only allowing the javascript to access the data layer values, no other DOM element
* restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and javascript code

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<nowiki><script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script></nowiki>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because sometimes you can get '''secure''' but '''not working''' 3rd party code when the vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki>
<html>
<head></head>
<body>
...

<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html></nowiki>

<nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Virtual iframe Containment ==

This technique creates iFrames that run asynchronously in relation to the main page. It also provides its own containment javascript that automates the dynamic implementation of the protected iFrames based on the marketing tag requirements.

== Vendor Agreements ==

You can have the agreement or request for proposal with the 3rd parties require evidence that they have implemented secure coding and general corporate server access security. But in particular you need to determine the monitoring and control of their source code in order to prevent and detect malicious changes to that javascript.

= MarTechSec =

Marketing Technology Security

This refers to all aspects of reducing the risk from marketing javascript. Controls include

1. Contractual controls for risk reduction; the contracts with any MarTech company should include a requirement to show evidence of code security and code integrity monitoring.

2. Contractual controls for risk transference: the contracts with any MarTech company could include a penalty for serving malicious javascript

3. Technical controls for malicious javascript execution prevention; Virtual Iframes,

4. Technical controls for malicious javascript identification; Subresource Integrity

5. Technical controls including client side javascript malicious behavior in penetration testing requirements

= MarSecOps =
Marketing Security Operations

This refers to the operational requirements to maintain some of the technical controls. This involves possible cooperation and information exchange between the marketing team, the martech provider and the run or operations team to update the information in the page controls (SRI hash change, changes in pages with SRI), the policies in the Virtual iFrames, tag manager configuration, data layer changes etc.

The most complete and preventive controls for any site containing non-trivial marketing tags are -

1. A data layer that calls the marketing server or tag manager APIs , so that only your code executes on your page (inversion of control)

2. Subresource Integrity

2. Virtual frame Containment.

The MarSecOps requirements to implement technical controls at the speed of change that marketing wants or without a significant number of dedicated resources, can make data layer and Subresource Integrity controls impractical.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

https://www.riskiq.com/blog/labs/magecart-ticketmaster-breach/

https://www.clearskysec.com/magecart/

https://www.riskiq.com/blog/labs/magecart-keylogger-injection/

https://www.zdnet.com/article/inbenta-blamed-for-ticketmaster-breach-says-other-sites-not-affected/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br />

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]
|}

3rd Party Javascript Management Cheat Sheet

2018-07-16T15:46:25Z

Jweiler: added links to Ticketmaster breach and good explanations with actual code

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Tags, aka marketing tags, analytics tags etc. are small bits of javascript on a web page. They can also be HTML image elements when javascript is disabled. The reason for them is to collect data on the web user actions and browsing context for use by the web page owner in marketing.

Third party vendor javascript tags (hereinafter, '''tags''') can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =
The single greatest risk is a compromise of the third party javascript server, and the injection of malicious javascript into the original tag javascript. This has happened in 2018 and likely earlier.

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for '''tags'''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html></nowiki>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki>
<html>
<head></head>
<body>
...

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or '''tag manager''' site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a '''container''' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

<nowiki>
<html>
<head></head>
<body>
...

<script>(function(w, d, s, l, i){
w[l] = w[l] || [];
w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : '';
j.async=true;
j.src='https://tagmanager.com/tm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>

</body>
</html></nowiki>

=== Security Problems with requesting Tags ===

The previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. One way to manage this risk is with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This is a secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement:

* technical controls such as only allowing the javascript to access the data layer values, no other DOM element
* restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and javascript code

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<nowiki><script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script></nowiki>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because sometimes you can get '''secure''' but '''not working''' 3rd party code when the vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki>
<html>
<head></head>
<body>
...

<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html></nowiki>

<nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Virtual iframe Containment ==

This technique creates iFrames that run asynchronously in relation to the main page. It also provides its own containment javascript that automates the dynamic implementation of the protected iFrames based on the marketing tag requirements.

== Vendor Agreements ==

You can have the agreement or request for proposal with the 3rd parties require evidence that they have implemented secure coding and general corporate server access security. But in particular you need to determine the monitoring and control of their source code in order to prevent and detect malicious changes to that javascript.

= MarTechSec =

Marketing Technology Security

This refers to all aspects of reducing the risk from marketing javascript. Controls include

1. Contractual controls for risk reduction; the contracts with any MarTech company should include a requirement to show evidence of code security and code integrity monitoring.

2. Contractual controls for risk transference: the contracts with any MarTech company could include a penalty for serving malicious javascript

3. Technical controls for malicious javascript execution prevention; Virtual Iframes,

4. Technical controls for malicious javascript identification; Subresource Integrity

5. Technical controls including client side javascript malicious behavior in penetration testing requirements

= MarSecOps =
Marketing Security Operations

This refers to the operational requirements to maintain some of the technical controls. This involves possible cooperation and information exchange between the marketing team, the martech provider and the run or operations team to update the information in the page controls (SRI hash change, changes in pages with SRI), the policies in the Virtual iFrames, tag manager configuration, data layer changes etc.

The most complete and preventive controls for any site containing non-trivial marketing tags are -

1. A data layer that calls the marketing server or tag manager APIs , so that only your code executes on your page (inversion of control)

2. Subresource Integrity

2. Virtual frame Containment.

The MarSecOps requirements to implement technical controls at the speed of change that marketing wants or without a significant number of dedicated resources, can make data layer and Subresource Integrity controls impractical.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

https://www.riskiq.com/blog/labs/magecart-ticketmaster-breach/

https://www.clearskysec.com/magecart/

https://www.riskiq.com/blog/labs/magecart-keylogger-injection/

https://www.zdnet.com/article/inbenta-blamed-for-ticketmaster-breach-says-other-sites-not-affected/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

CORS OriginHeaderScrutiny

2018-05-30T01:45:37Z

Jweiler: syntax corrections

{{taggedDocument
| type=pls_review
}}

Last revision (mm/dd/yy): '''08/16/2013'''

== Introduction ==

'''CORS''' stands for '''C'''ross-'''O'''rigin '''R'''esource '''S'''haring.

Is a feature offering the possbility for:
* A web application to expose resources to all or restricted domain,
* A web client to make AJAX request for resource on other domain than is source domain.

This article will focus on the role of the '''Origin''' header in the exchange between web client and web application.

The basic process is composed of the steps below (sample HTTP resquest/response has been taken from [https://developer.mozilla.org/en-US/docs/HTTP_access_control Mozilla Wiki]):

* '''Step 1 : Web client sends a request to get a resource from a different domain.'''

<pre>
GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
Origin: http://foo.example

[Request Body]
</pre>

The web client tells the server its source domain using the HTTP request header "'''Origin'''".

* '''Step 2 : Web application response to request.'''

<pre>
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml
Access-Control-Allow-Origin: *

[Response Body]
</pre>

The web application informs the web client of the allowed domains using the HTTP response header '''Access-Control-Allow-Origin'''.
The header can contains either a '*' to indicate that all domains are allowed OR a specified domain to indicate the specified allowed domain.

* '''Step 3 : Web client process web application response.'''

According to the CORS W3C specification, it's up to the web client (usually a browser) to determine, using the web application response HTTP header '''Access-Control-Allow-Origin''',
if the web client is allowed to access response data.

== Risk ==

''A reminder : This article will focus on the web application side because it's the only part in which we have the maximum of control.''

The risk here is that a web client can put any value into the '''Origin''' request HTTP header in order to force web application to provide it the target resource content.
In the case of a Browser web client, the header value is managed by the browser but another "web client" can be used (like Curl/Wget/Burp suite/...) to change/override the "Origin" header value...

== Countermeasure ==

'''Option A: Use CORS authenticated request'''

In this option, we enable authentication on the resources accessed and require that the user/application credentials be passed with the [https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS#Requests_with_credentials CORS requests].

If the CORS resources exposed are classified as sensitive (and CORS exposition is mandatory) it's a good option but if the objective is only to ensure that the request originator is really
one of the allowed (to avoid rogue call), there somes drawback with this option, among others:
* The target application must manage users (or applications) credentials repositories including features like password expiry, password reset, brute force prevention, account lock/unlock,...
* The client application must store (in a secure way) the credentials to use,
* The client application must manage/configure credentials transfer in HTTP request in order that credentials are send only in case of CORS requests to target application.

'''Option B: We can scrutiny the Origin header value on server side'''

In this option, the objective is to work between steps 1 and 2 of the CORS HTTP requests/responses exchange process (see above).

To achieve it, we will use JEE Web Filter that will ensure the following points for each incoming HTTP CORS requests:
# Have only one non empty instance of the '''origin''' header,
# Have only one non empty instance of the '''host''' header,
# The value of the origin header is present in an internal allowed domains list (white list). This check is done before step 2 of the CORS HTTP requests/responses exchange process, and the allowed domains list will be provided to the client,
# Cache IP of the sender for 1 hour. If the sender sends any requests with an origin domain that is not in the white list then all requests will return an HTTP 403 response (protract allowed domain guessing).

We use the method above because it's not possible to be 100% certain that any request comes from an expected client application, since:
* All information of a HTTP request can be faked,
* It's the browser (or others tools) that send the HTTP request then the IP address that we have access to is the client IP address.

<pre style="color:#88421D">In a Enterprise inter application communication it's possible to add a check on the client IP range.
"Business to business" communication offer possibility to for each part to indicate to others parts the IP range that it will
be used by its applications.</pre>

'''Sample implementation: Filter class'''

<pre>

import java.io.IOException;
import java.util.ArrayList;
import java.util.Collections;
import java.util.Enumeration;
import java.util.List;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.annotation.WebFilter;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import net.sf.ehcache.Cache;
import net.sf.ehcache.CacheManager;
import net.sf.ehcache.Element;
import net.sf.ehcache.config.CacheConfiguration;
import net.sf.ehcache.config.PersistenceConfiguration;
import net.sf.ehcache.store.MemoryStoreEvictionPolicy;

/**
* Sample filter implementation to scrutiny CORS "Origin" HTTP header.<br/>
*
* This implementation has a dependency on EHCache API because<br/>
* it use Caching for blacklisted client IP in order to enhance performance.
*
* Assume here that all CORS resources are grouped in context path "/cors/".
*
*/
@WebFilter("/cors/*")
public class CORSOriginHeaderScrutiny implements Filter {

/** Filter configuration */
@SuppressWarnings("unused")
private FilterConfig filterConfig = null;

/** Cache used to cache blacklisted Clients (request sender) IP address */
private Cache blackListedClientIPCache = null;

/** Domains allowed to access to resources (white list) */
private List<String> allowedDomains = new ArrayList<String>();

/**
* {@inheritDoc}
*
* @see Filter#init(FilterConfig)
*/
@Override
public void init(FilterConfig fConfig) throws ServletException {
// Get filter configuration
this.filterConfig = fConfig;
// Initialize Client IP address dedicated cache with a cache of 60 minutes expiration delay for each item
PersistenceConfiguration cachePersistence = new PersistenceConfiguration();
cachePersistence.strategy(PersistenceConfiguration.Strategy.NONE);
CacheConfiguration cacheConfig = new CacheConfiguration().memoryStoreEvictionPolicy(MemoryStoreEvictionPolicy.FIFO)
.eternal(false)
.timeToLiveSeconds(3600)
.diskExpiryThreadIntervalSeconds(450)
.persistence(cachePersistence)
.maxEntriesLocalHeap(10000)
.logging(false);
cacheConfig.setName("BlackListedClientsCacheConfig");
this.blackListedClientIPCache = new Cache(cacheConfig);
this.blackListedClientIPCache.setName("BlackListedClientsCache");
CacheManager.getInstance().addCache(this.blackListedClientIPCache);
// Load domains allowed white list (hard coded here only for example)
this.allowedDomains.add("http://www.html5rocks.com");
this.allowedDomains.add("https://www.mydomains.com");
}

/**
* {@inheritDoc}
*
* @see Filter#destroy()
*/
@Override
public void destroy() {
// Remove Cache
CacheManager.getInstance().removeCache("BlackListedClientsCache");
}

/**
* {@inheritDoc}
*
* @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)
*/
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
HttpServletRequest httpRequest = ((HttpServletRequest) request);
HttpServletResponse httpResponse = ((HttpServletResponse) response);
List<String> headers = null;
boolean isValid = false;
String origin = null;
String clientIP = httpRequest.getRemoteAddr();

/* Step 0 : Check presence of client IP in black list */
if (this.blackListedClientIPCache.isKeyInCache(clientIP)) {
// Return HTTP Error without any information about cause of the request reject !
httpResponse.sendError(HttpServletResponse.SC_FORBIDDEN);
// Add trace here
// ....
// Quick Exit
return;
}

/* Step 1 : Check that we have only one and non empty instance of the "Origin" header */
headers = CORSOriginHeaderScrutiny.enumAsList(httpRequest.getHeaders("Origin"));
if ((headers == null) || (headers.size() != 1)) {
// If we reach this point it means that we have multiple instance of the "Origin" header
// Add client IP address to black listed client
addClientToBlacklist(clientIP);
// Return HTTP Error without any information about cause of the request reject !
httpResponse.sendError(HttpServletResponse.SC_FORBIDDEN);
// Add trace here
// ....
// Quick Exit
return;
}
origin = headers.get(0);

/* Step 2 : Check that we have only one and non empty instance of the "Host" header */
headers = CORSOriginHeaderScrutiny.enumAsList(httpRequest.getHeaders("Host"));
if ((headers == null) || (headers.size() != 1)) {
// If we reach this point it means that we have multiple instance of the "Host" header
// Add client IP address to black listed client
addClientToBlacklist(clientIP);
// Return HTTP Error without any information about cause of the request reject !
httpResponse.sendError(HttpServletResponse.SC_FORBIDDEN);
// Add trace here
// ....
// Quick Exit
return;
}

/* Step 3 : Perform analysis - Origin header is required */
if ((origin != null) && !"".equals(origin.trim())) {
if (this.allowedDomains.contains(origin)) {
// Check if origin is in allowed domain
isValid = true;
} else {
// Add client IP address to black listed client
addClientToBlacklist(clientIP);
isValid = false;
// Add trace here
// ....
}
}

/* Step 4 : Finalize request next step */
if (isValid) {
// Analysis OK then pass the request along the filter chain
chain.doFilter(request, response);
} else {
// Return HTTP Error without any information about cause of the request reject !
httpResponse.sendError(HttpServletResponse.SC_FORBIDDEN);
}
}

/**
* Blacklist client
*
* @param clientIP Client IP address
*/
private void addClientToBlacklist(String clientIP) {
// Add client IP address to black listed client
Element cacheElement = new Element(clientIP, clientIP);
this.blackListedClientIPCache.put(cacheElement);
}

/**
* Convert a enumeration to a list
*
* @param tmpEnum Enumeration to convert
* @return list of string or null is input enumeration is null
*/
private static List<String> enumAsList(Enumeration<String> tmpEnum) {
if (tmpEnum != null) {
return Collections.list(tmpEnum);
}
return null;
}
}

</pre>

'''Note:'''
[[Automated Audit using W3AF|W3AF]] audit tools (http://w3af.org) contains plugins to automatically audit web
application to check if they implements this type of countermeasure.

<pre style="color:#088A08">
It's very useful to include this type of tools into a web application development process in order to
perform a regular automatic first level check (do not replace an manual audit and manual audit must be also conducted regularly).
</pre>

== Informations links ==

* W3C Specification : http://www.w3.org/TR/cors/
* Mozilla Wiki : https://developer.mozilla.org/en-US/docs/HTTP_access_control
* Wikipedia : http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
* CORS Abuse : http://blog.secureideas.com/2013/02/grab-cors-light.html

[[Category:Java]]
[[Category:Attack]]
[[Category:Injection Attack]]

CORS OriginHeaderScrutiny

2018-05-30T01:43:29Z

Jweiler: more syntax corrections

{{taggedDocument
| type=pls_review
}}

Last revision (mm/dd/yy): '''08/16/2013'''

== Introduction ==

'''CORS''' stands for '''C'''ross-'''O'''rigin '''R'''esource '''S'''haring.

Is a feature offering the possbility for:
* A web application to expose resources to all or restricted domain,
* A web client to make AJAX request for resource on other domain than is source domain.

This article will focus on the role of the '''Origin''' header in the exchange between web client and web application.

The basic process is composed of the steps below (sample HTTP resquest/response has been taken from [https://developer.mozilla.org/en-US/docs/HTTP_access_control Mozilla Wiki]):

* '''Step 1 : Web client sends a request to get a resource from a different domain.'''

<pre>
GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
Origin: http://foo.example

[Request Body]
</pre>

The web client tell the server its source domain using the HTTP request header "'''Origin'''".

* '''Step 2 : Web application response to request.'''

<pre>
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml
Access-Control-Allow-Origin: *

[Response Body]
</pre>

The web application informs web client of the allowed domain using the HTTP response header '''Access-Control-Allow-Origin'''.
The header can contains a '*' to indicate that all domain are allowed OR a specified domain to indicate the specified allowed domain.

* '''Step 3 : Web client process web application response.'''

According to the CORS W3C specification, it's up to the web client (usually a browser) to determine, using the web application response HTTP header '''Access-Control-Allow-Origin''',
if the web client is allowed to access response data.

== Risk ==

''A reminder : This article will focus on the web application side because it's the only part in which we have the maximum of control.''

The risk here is that a web client can put any value into the '''Origin''' request HTTP header in order to force web application to provide it the target resource content.
In the case of a Browser web client, the header value is managed by the browser but another "web client" can be used (like Curl/Wget/Burp suite/...) to change/override the "Origin" header value...

== Countermeasure ==

'''Option A: Use CORS authenticated request'''

In this option, we enable authentication on the resources accessed and require that the user/application credentials be passed with the [https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS#Requests_with_credentials CORS requests].

If the CORS resources exposed are classified as sensitive (and CORS exposition is mandatory) it's a good option but if the objective is only to ensure that the request originator is really
one of the allowed (to avoid rogue call), there somes drawback with this option, among others:
* The target application must manage users (or applications) credentials repositories including features like password expiry, password reset, brute force prevention, account lock/unlock,...
* The client application must store (in a secure way) the credentials to use,
* The client application must manage/configure credentials transfer in HTTP request in order that credentials are send only in case of CORS requests to target application.

'''Option B: We can scrutiny the Origin header value on server side'''

In this option, the objective is to work between steps 1 and 2 of the CORS HTTP requests/responses exchange process (see above).

To achieve it, we will use JEE Web Filter that will ensure the following points for each incoming HTTP CORS requests:
# Have only one non empty instance of the '''origin''' header,
# Have only one non empty instance of the '''host''' header,
# The value of the origin header is present in an internal allowed domains list (white list). This check is done before step 2 of the CORS HTTP requests/responses exchange process, and the allowed domains list will be provided to the client,
# Cache IP of the sender for 1 hour. If the sender sends any requests with an origin domain that is not in the white list then all requests will return an HTTP 403 response (protract allowed domain guessing).

We use the method above because it's not possible to be 100% certain that any request comes from an expected client application, since:
* All information of a HTTP request can be faked,
* It's the browser (or others tools) that send the HTTP request then the IP address that we have access to is the client IP address.

<pre style="color:#88421D">In a Enterprise inter application communication it's possible to add a check on the client IP range.
"Business to business" communication offer possibility to for each part to indicate to others parts the IP range that it will
be used by its applications.</pre>

'''Sample implementation: Filter class'''

<pre>

import java.io.IOException;
import java.util.ArrayList;
import java.util.Collections;
import java.util.Enumeration;
import java.util.List;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.annotation.WebFilter;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import net.sf.ehcache.Cache;
import net.sf.ehcache.CacheManager;
import net.sf.ehcache.Element;
import net.sf.ehcache.config.CacheConfiguration;
import net.sf.ehcache.config.PersistenceConfiguration;
import net.sf.ehcache.store.MemoryStoreEvictionPolicy;

/**
* Sample filter implementation to scrutiny CORS "Origin" HTTP header.<br/>
*
* This implementation has a dependency on EHCache API because<br/>
* it use Caching for blacklisted client IP in order to enhance performance.
*
* Assume here that all CORS resources are grouped in context path "/cors/".
*
*/
@WebFilter("/cors/*")
public class CORSOriginHeaderScrutiny implements Filter {

/** Filter configuration */
@SuppressWarnings("unused")
private FilterConfig filterConfig = null;

/** Cache used to cache blacklisted Clients (request sender) IP address */
private Cache blackListedClientIPCache = null;

/** Domains allowed to access to resources (white list) */
private List<String> allowedDomains = new ArrayList<String>();

/**
* {@inheritDoc}
*
* @see Filter#init(FilterConfig)
*/
@Override
public void init(FilterConfig fConfig) throws ServletException {
// Get filter configuration
this.filterConfig = fConfig;
// Initialize Client IP address dedicated cache with a cache of 60 minutes expiration delay for each item
PersistenceConfiguration cachePersistence = new PersistenceConfiguration();
cachePersistence.strategy(PersistenceConfiguration.Strategy.NONE);
CacheConfiguration cacheConfig = new CacheConfiguration().memoryStoreEvictionPolicy(MemoryStoreEvictionPolicy.FIFO)
.eternal(false)
.timeToLiveSeconds(3600)
.diskExpiryThreadIntervalSeconds(450)
.persistence(cachePersistence)
.maxEntriesLocalHeap(10000)
.logging(false);
cacheConfig.setName("BlackListedClientsCacheConfig");
this.blackListedClientIPCache = new Cache(cacheConfig);
this.blackListedClientIPCache.setName("BlackListedClientsCache");
CacheManager.getInstance().addCache(this.blackListedClientIPCache);
// Load domains allowed white list (hard coded here only for example)
this.allowedDomains.add("http://www.html5rocks.com");
this.allowedDomains.add("https://www.mydomains.com");
}

/**
* {@inheritDoc}
*
* @see Filter#destroy()
*/
@Override
public void destroy() {
// Remove Cache
CacheManager.getInstance().removeCache("BlackListedClientsCache");
}

/**
* {@inheritDoc}
*
* @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)
*/
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
HttpServletRequest httpRequest = ((HttpServletRequest) request);
HttpServletResponse httpResponse = ((HttpServletResponse) response);
List<String> headers = null;
boolean isValid = false;
String origin = null;
String clientIP = httpRequest.getRemoteAddr();

/* Step 0 : Check presence of client IP in black list */
if (this.blackListedClientIPCache.isKeyInCache(clientIP)) {
// Return HTTP Error without any information about cause of the request reject !
httpResponse.sendError(HttpServletResponse.SC_FORBIDDEN);
// Add trace here
// ....
// Quick Exit
return;
}

/* Step 1 : Check that we have only one and non empty instance of the "Origin" header */
headers = CORSOriginHeaderScrutiny.enumAsList(httpRequest.getHeaders("Origin"));
if ((headers == null) || (headers.size() != 1)) {
// If we reach this point it means that we have multiple instance of the "Origin" header
// Add client IP address to black listed client
addClientToBlacklist(clientIP);
// Return HTTP Error without any information about cause of the request reject !
httpResponse.sendError(HttpServletResponse.SC_FORBIDDEN);
// Add trace here
// ....
// Quick Exit
return;
}
origin = headers.get(0);

/* Step 2 : Check that we have only one and non empty instance of the "Host" header */
headers = CORSOriginHeaderScrutiny.enumAsList(httpRequest.getHeaders("Host"));
if ((headers == null) || (headers.size() != 1)) {
// If we reach this point it means that we have multiple instance of the "Host" header
// Add client IP address to black listed client
addClientToBlacklist(clientIP);
// Return HTTP Error without any information about cause of the request reject !
httpResponse.sendError(HttpServletResponse.SC_FORBIDDEN);
// Add trace here
// ....
// Quick Exit
return;
}

/* Step 3 : Perform analysis - Origin header is required */
if ((origin != null) && !"".equals(origin.trim())) {
if (this.allowedDomains.contains(origin)) {
// Check if origin is in allowed domain
isValid = true;
} else {
// Add client IP address to black listed client
addClientToBlacklist(clientIP);
isValid = false;
// Add trace here
// ....
}
}

/* Step 4 : Finalize request next step */
if (isValid) {
// Analysis OK then pass the request along the filter chain
chain.doFilter(request, response);
} else {
// Return HTTP Error without any information about cause of the request reject !
httpResponse.sendError(HttpServletResponse.SC_FORBIDDEN);
}
}

/**
* Blacklist client
*
* @param clientIP Client IP address
*/
private void addClientToBlacklist(String clientIP) {
// Add client IP address to black listed client
Element cacheElement = new Element(clientIP, clientIP);
this.blackListedClientIPCache.put(cacheElement);
}

/**
* Convert a enumeration to a list
*
* @param tmpEnum Enumeration to convert
* @return list of string or null is input enumeration is null
*/
private static List<String> enumAsList(Enumeration<String> tmpEnum) {
if (tmpEnum != null) {
return Collections.list(tmpEnum);
}
return null;
}
}

</pre>

'''Note:'''
[[Automated Audit using W3AF|W3AF]] audit tools (http://w3af.org) contains plugins to automatically audit web
application to check if they implements this type of countermeasure.

<pre style="color:#088A08">
It's very useful to include this type of tools into a web application development process in order to
perform a regular automatic first level check (do not replace an manual audit and manual audit must be also conducted regularly).
</pre>

== Informations links ==

* W3C Specification : http://www.w3.org/TR/cors/
* Mozilla Wiki : https://developer.mozilla.org/en-US/docs/HTTP_access_control
* Wikipedia : http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
* CORS Abuse : http://blog.secureideas.com/2013/02/grab-cors-light.html

[[Category:Java]]
[[Category:Attack]]
[[Category:Injection Attack]]

Talk:CORS OriginHeaderScrutiny

2018-05-30T01:38:53Z

Jweiler: request for clarification of some statements

what does "protract allowed domain guessing" mean?

I don't understand what this is trying to say - "It's the browser (or others tools) that send the HTTP request then the IP address that we have access to is the client IP address"

Talk:CORS OriginHeaderScrutiny

2018-05-30T01:36:49Z

Jweiler: Created page with "what does "protract allowed domain guessing" mean?"

what does "protract allowed domain guessing" mean?

CORS OriginHeaderScrutiny

2018-05-30T01:36:13Z

Jweiler:

{{taggedDocument
| type=pls_review
}}

Last revision (mm/dd/yy): '''08/16/2013'''

== Introduction ==

'''CORS''' stands for '''C'''ross-'''O'''rigin '''R'''esource '''S'''haring.

Is a feature offering the possbility for:
* A web application to expose resources to all or restricted domain,
* A web client to make AJAX request for resource on other domain than is source domain.

This article will focus on role of the '''Origin''' header in exchange between web client and web application.

The basic process is composed by steps below (sample HTTP resquest/response has been taken from [https://developer.mozilla.org/en-US/docs/HTTP_access_control Mozilla Wiki]):

* '''Step 1 : Web client send request to get resource from a different domain.'''

<pre>
GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
Origin: http://foo.example

[Request Body]
</pre>

The web client inform is source domain using the HTTP request header "'''Origin'''".

* '''Step 2 : Web application respond to request.'''

<pre>
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml
Access-Control-Allow-Origin: *

[Response Body]
</pre>

The web application informs web client of the allowed domain using the HTTP response header '''Access-Control-Allow-Origin'''.
The header can contains a '*' to indicate that all domain are allowed OR a specified domain to indicate the specified allowed domain.

* '''Step 3 : Web client process web application response.'''

According to the CORS W3C specification, it's up to the web client (usually a browser) to determine, using the web application response HTTP header '''Access-Control-Allow-Origin''',
if the web client is allowed to access response data.

== Risk ==

''A reminder : Into this article we focus on web application side because it's the only part in which we have the maximum of control.''

The risk here is that a web client can put any value into the '''Origin''' request HTTP header in order to force web application to provide it the target resource content.
In the case of a Browser web client, the header value is managed by the browser but another "web client" can be used (like Curl/Wget/Burp suite/...) to change/override the "Origin" header value...

== Countermeasure ==

'''Option A: Use CORS authenticated request'''

In this option, we enable authentication on the resources accessed and require that the user/application credentials be passed with the [https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS#Requests_with_credentials CORS requests].

If the CORS resources exposed are classified as sensitive (and CORS exposition is mandatory) it's a good option but if the objective is only to ensure that the request originator is really
one of the allowed (to avoid rogue call), there somes drawback with this option, among others:
* The target application must manage users (or applications) credentials repositories including features like password expiry, password reset, brute force prevention, account lock/unlock,...
* The client application must store (in a secure way) the credentials to use,
* The client application must manage/configure credentials transfer in HTTP request in order that credentials are send only in case of CORS requests to target application.

'''Option B: We can scrutiny the Origin header value on server side'''

In this option, the objective is to work between steps 1 and 2 of the CORS HTTP requests/responses exchange process (see above).

To achieve it, we will use JEE Web Filter that will ensure the following points for each incoming HTTP CORS requests:
# Have only one non empty instance of the '''origin''' header,
# Have only one non empty instance of the '''host''' header,
# The value of the origin header is present in an internal allowed domains list (white list). This check is done before step 2 of the CORS HTTP requests/responses exchange process, and the allowed domains list will be provided to the client,
# Cache IP of the sender for 1 hour. If the sender sends any requests with an origin domain that is not in the white list then all requests will return an HTTP 403 response (protract allowed domain guessing).

We use the method above because it's not possible to be 100% certain that any request comes from an expected client application, since:
* All information of a HTTP request can be faked,
* It's the browser (or others tools) that send the HTTP request then the IP address that we have access to is the client IP address.

<pre style="color:#88421D">In a Enterprise inter application communication it's possible to add a check on the client IP range.
"Business to business" communication offer possibility to for each part to indicate to others parts the IP range that it will
be used by its applications.</pre>

'''Sample implementation: Filter class'''

<pre>

import java.io.IOException;
import java.util.ArrayList;
import java.util.Collections;
import java.util.Enumeration;
import java.util.List;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.annotation.WebFilter;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import net.sf.ehcache.Cache;
import net.sf.ehcache.CacheManager;
import net.sf.ehcache.Element;
import net.sf.ehcache.config.CacheConfiguration;
import net.sf.ehcache.config.PersistenceConfiguration;
import net.sf.ehcache.store.MemoryStoreEvictionPolicy;

/**
* Sample filter implementation to scrutiny CORS "Origin" HTTP header.<br/>
*
* This implementation has a dependency on EHCache API because<br/>
* it use Caching for blacklisted client IP in order to enhance performance.
*
* Assume here that all CORS resources are grouped in context path "/cors/".
*
*/
@WebFilter("/cors/*")
public class CORSOriginHeaderScrutiny implements Filter {

/** Filter configuration */
@SuppressWarnings("unused")
private FilterConfig filterConfig = null;

/** Cache used to cache blacklisted Clients (request sender) IP address */
private Cache blackListedClientIPCache = null;

/** Domains allowed to access to resources (white list) */
private List<String> allowedDomains = new ArrayList<String>();

/**
* {@inheritDoc}
*
* @see Filter#init(FilterConfig)
*/
@Override
public void init(FilterConfig fConfig) throws ServletException {
// Get filter configuration
this.filterConfig = fConfig;
// Initialize Client IP address dedicated cache with a cache of 60 minutes expiration delay for each item
PersistenceConfiguration cachePersistence = new PersistenceConfiguration();
cachePersistence.strategy(PersistenceConfiguration.Strategy.NONE);
CacheConfiguration cacheConfig = new CacheConfiguration().memoryStoreEvictionPolicy(MemoryStoreEvictionPolicy.FIFO)
.eternal(false)
.timeToLiveSeconds(3600)
.diskExpiryThreadIntervalSeconds(450)
.persistence(cachePersistence)
.maxEntriesLocalHeap(10000)
.logging(false);
cacheConfig.setName("BlackListedClientsCacheConfig");
this.blackListedClientIPCache = new Cache(cacheConfig);
this.blackListedClientIPCache.setName("BlackListedClientsCache");
CacheManager.getInstance().addCache(this.blackListedClientIPCache);
// Load domains allowed white list (hard coded here only for example)
this.allowedDomains.add("http://www.html5rocks.com");
this.allowedDomains.add("https://www.mydomains.com");
}

/**
* {@inheritDoc}
*
* @see Filter#destroy()
*/
@Override
public void destroy() {
// Remove Cache
CacheManager.getInstance().removeCache("BlackListedClientsCache");
}

/**
* {@inheritDoc}
*
* @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)
*/
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
HttpServletRequest httpRequest = ((HttpServletRequest) request);
HttpServletResponse httpResponse = ((HttpServletResponse) response);
List<String> headers = null;
boolean isValid = false;
String origin = null;
String clientIP = httpRequest.getRemoteAddr();

/* Step 0 : Check presence of client IP in black list */
if (this.blackListedClientIPCache.isKeyInCache(clientIP)) {
// Return HTTP Error without any information about cause of the request reject !
httpResponse.sendError(HttpServletResponse.SC_FORBIDDEN);
// Add trace here
// ....
// Quick Exit
return;
}

/* Step 1 : Check that we have only one and non empty instance of the "Origin" header */
headers = CORSOriginHeaderScrutiny.enumAsList(httpRequest.getHeaders("Origin"));
if ((headers == null) || (headers.size() != 1)) {
// If we reach this point it means that we have multiple instance of the "Origin" header
// Add client IP address to black listed client
addClientToBlacklist(clientIP);
// Return HTTP Error without any information about cause of the request reject !
httpResponse.sendError(HttpServletResponse.SC_FORBIDDEN);
// Add trace here
// ....
// Quick Exit
return;
}
origin = headers.get(0);

/* Step 2 : Check that we have only one and non empty instance of the "Host" header */
headers = CORSOriginHeaderScrutiny.enumAsList(httpRequest.getHeaders("Host"));
if ((headers == null) || (headers.size() != 1)) {
// If we reach this point it means that we have multiple instance of the "Host" header
// Add client IP address to black listed client
addClientToBlacklist(clientIP);
// Return HTTP Error without any information about cause of the request reject !
httpResponse.sendError(HttpServletResponse.SC_FORBIDDEN);
// Add trace here
// ....
// Quick Exit
return;
}

/* Step 3 : Perform analysis - Origin header is required */
if ((origin != null) && !"".equals(origin.trim())) {
if (this.allowedDomains.contains(origin)) {
// Check if origin is in allowed domain
isValid = true;
} else {
// Add client IP address to black listed client
addClientToBlacklist(clientIP);
isValid = false;
// Add trace here
// ....
}
}

/* Step 4 : Finalize request next step */
if (isValid) {
// Analysis OK then pass the request along the filter chain
chain.doFilter(request, response);
} else {
// Return HTTP Error without any information about cause of the request reject !
httpResponse.sendError(HttpServletResponse.SC_FORBIDDEN);
}
}

/**
* Blacklist client
*
* @param clientIP Client IP address
*/
private void addClientToBlacklist(String clientIP) {
// Add client IP address to black listed client
Element cacheElement = new Element(clientIP, clientIP);
this.blackListedClientIPCache.put(cacheElement);
}

/**
* Convert a enumeration to a list
*
* @param tmpEnum Enumeration to convert
* @return list of string or null is input enumeration is null
*/
private static List<String> enumAsList(Enumeration<String> tmpEnum) {
if (tmpEnum != null) {
return Collections.list(tmpEnum);
}
return null;
}
}

</pre>

'''Note:'''
[[Automated Audit using W3AF|W3AF]] audit tools (http://w3af.org) contains plugins to automatically audit web
application to check if they implements this type of countermeasure.

<pre style="color:#088A08">
It's very useful to include this type of tools into a web application development process in order to
perform a regular automatic first level check (do not replace an manual audit and manual audit must be also conducted regularly).
</pre>

== Informations links ==

* W3C Specification : http://www.w3.org/TR/cors/
* Mozilla Wiki : https://developer.mozilla.org/en-US/docs/HTTP_access_control
* Wikipedia : http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
* CORS Abuse : http://blog.secureideas.com/2013/02/grab-cors-light.html

[[Category:Java]]
[[Category:Attack]]
[[Category:Injection Attack]]

Talk:SameSite

2018-05-02T21:47:57Z

Jweiler: asking about expired rfc6265bis which is the only doc to define SameSite

I know browsers have implemented the SameSite attribute, but the only IETF document that defines it is draft-ietf-httpbis-rfc6265bis-02, which is expired. RFC6265 does not include the SameSite attribute. Do browsers choose to implement draft specs on their own?

User:Jweiler

2018-04-26T15:47:25Z

Jweiler: added my coining MarTechSec and MarSecOps

I started programming in Fortran in 1970. I wrote a COBOL program as an undergraduate. I actually wrote a program in APL at UMASS Amherst in 1978 as a graduate student. I put a 'Hello World' website from my portable computer at work on the internet without a firewall in 1996, just for a few hours, and just an IP address, no DNS name.
In 2005 I started the Boston OWASP chapter, and am still running it.
I got involved in application security at Staples from 2001 to 2007. I was the application security architect for Starwood Hotels from 2007 to 2017. Starwood was acquired by Marriott in 2017 and I'm currently an application security guy for Marriott. I've been focusing on client side application code and I coined the terms 'MarTechSec' and 'MarSecOps' on April 19 in my 3rd party JavaScript Management Cheatsheet page.

User:Jweiler

2018-04-26T15:44:25Z

Jweiler: added more work history - Staples, MI.

3rd Party Javascript Management Cheat Sheet

2018-04-18T19:15:18Z

Jweiler: /* MarSecOps */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Tags, aka marketing tags, analytics tags etc. are small bits of javascript on a web page. They can also be HTML image elements when javascript is disabled. The reason for them is to collect data on the web user actions and browsing context for use by the web page owner in marketing.

Third party vendor javascript tags (hereinafter, '''tags''') can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =
The single greatest risk is a compromise of the third party javascript server, and the injection of malicious javascript into the original tag javascript. This has happened in 2018 and likely earlier.

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for '''tags'''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html></nowiki>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki>
<html>
<head></head>
<body>
...

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or '''tag manager''' site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a '''container''' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

<nowiki>
<html>
<head></head>
<body>
...

<script>(function(w, d, s, l, i){
w[l] = w[l] || [];
w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : '';
j.async=true;
j.src='https://tagmanager.com/tm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>

</body>
</html></nowiki>

=== Security Problems with requesting Tags ===

The previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. One way to manage this risk is with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This is a secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement:

* technical controls such as only allowing the javascript to access the data layer values, no other DOM element
* restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and javascript code

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<nowiki><script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script></nowiki>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because sometimes you can get '''secure''' but '''not working''' 3rd party code when the vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki>
<html>
<head></head>
<body>
...

<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html></nowiki>

<nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Virtual iframe Containment ==

This technique creates iFrames that run asynchronously in relation to the main page. It also provides its own containment javascript that automates the dynamic implementation of the protected iFrames based on the marketing tag requirements.

== Vendor Agreements ==

You can have the agreement or request for proposal with the 3rd parties require evidence that they have implemented secure coding and general corporate server access security. But in particular you need to determine the monitoring and control of their source code in order to prevent and detect malicious changes to that javascript.

= MarTechSec =

Marketing Technology Security

This refers to all aspects of reducing the risk from marketing javascript. Controls include

1. Contractual controls for risk reduction; the contracts with any MarTech company should include a requirement to show evidence of code security and code integrity monitoring.

2. Contractual controls for risk transference: the contracts with any MarTech company could include a penalty for serving malicious javascript

3. Technical controls for malicious javascript execution prevention; Virtual Iframes,

4. Technical controls for malicious javascript identification; Subresource Integrity

5. Technical controls including client side javascript malicious behavior in penetration testing requirements

= MarSecOps =
Marketing Security Operations

This refers to the operational requirements to maintain some of the technical controls. This involves possible cooperation and information exchange between the marketing team, the martech provider and the run or operations team to update the information in the page controls (SRI hash change, changes in pages with SRI), the policies in the Virtual iFrames, tag manager configuration, data layer changes etc.

The most complete and preventive controls for any site containing non-trivial marketing tags are -

1. A data layer that calls the marketing server or tag manager APIs , so that only your code executes on your page (inversion of control)

2. Subresource Integrity

2. Virtual frame Containment.

The MarSecOps requirements to implement technical controls at the speed of change that marketing wants or without a significant number of dedicated resources, can make data layer and Subresource Integrity controls impractical.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2018-04-18T19:14:11Z

Jweiler:

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Tags, aka marketing tags, analytics tags etc. are small bits of javascript on a web page. They can also be HTML image elements when javascript is disabled. The reason for them is to collect data on the web user actions and browsing context for use by the web page owner in marketing.

Third party vendor javascript tags (hereinafter, '''tags''') can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =
The single greatest risk is a compromise of the third party javascript server, and the injection of malicious javascript into the original tag javascript. This has happened in 2018 and likely earlier.

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for '''tags'''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html></nowiki>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki>
<html>
<head></head>
<body>
...

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or '''tag manager''' site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a '''container''' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

<nowiki>
<html>
<head></head>
<body>
...

<script>(function(w, d, s, l, i){
w[l] = w[l] || [];
w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : '';
j.async=true;
j.src='https://tagmanager.com/tm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>

</body>
</html></nowiki>

=== Security Problems with requesting Tags ===

The previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. One way to manage this risk is with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This is a secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement:

* technical controls such as only allowing the javascript to access the data layer values, no other DOM element
* restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and javascript code

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<nowiki><script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script></nowiki>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because sometimes you can get '''secure''' but '''not working''' 3rd party code when the vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki>
<html>
<head></head>
<body>
...

<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html></nowiki>

<nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Virtual iframe Containment ==

This technique creates iFrames that run asynchronously in relation to the main page. It also provides its own containment javascript that automates the dynamic implementation of the protected iFrames based on the marketing tag requirements.

== Vendor Agreements ==

You can have the agreement or request for proposal with the 3rd parties require evidence that they have implemented secure coding and general corporate server access security. But in particular you need to determine the monitoring and control of their source code in order to prevent and detect malicious changes to that javascript.

= MarTechSec =

Marketing Technology Security

This refers to all aspects of reducing the risk from marketing javascript. Controls include

1. Contractual controls for risk reduction; the contracts with any MarTech company should include a requirement to show evidence of code security and code integrity monitoring.

2. Contractual controls for risk transference: the contracts with any MarTech company could include a penalty for serving malicious javascript

3. Technical controls for malicious javascript execution prevention; Virtual Iframes,

4. Technical controls for malicious javascript identification; Subresource Integrity

5. Technical controls including client side javascript malicious behavior in penetration testing requirements

= MarSecOps =
Marketing Security Operations

This refers to the operational requirements to maintain some of the technical controls. This involves possible cooperation and information exchange between the marketing team, the martech provider and the run or operations team to update the information in the page controls (SRI hash change, changes in pages with SRI), the policies in the Virtual iFrames, tag manager configuration, data layer changes etc.

The most complete controls for any site containing non-trivial marketing tags are -

1. a data layer that calls the marketing server or tag manager APIs , so that only your code executes on your page (inversion of control)

2. Subresource Integrity

2. Virtual frame Containment.

The MarSecOps requirements to implement technical controls at the speed of change that marketing wants or without a significant number of dedicated resources, can make data layer and Subresource Integrity controls impractical.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2018-04-18T19:07:41Z

Jweiler:

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Tags, aka marketing tags, analytics tags etc. are small bits of javascript on a web page. They can also be HTML image elements when javascript is disabled. The reason for them is to collect data on the web user actions and browsing context for use by the web page owner in marketing.

Third party vendor javascript tags (hereinafter, '''tags''') can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =
The single greatest risk is a compromise of the third party javascript server, and the injection of malicious javascript into the original tag javascript. This has happened in 2018 and likely earlier.

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for '''tags'''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html></nowiki>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki>
<html>
<head></head>
<body>
...

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or '''tag manager''' site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a '''container''' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

<nowiki>
<html>
<head></head>
<body>
...

<script>(function(w, d, s, l, i){
w[l] = w[l] || [];
w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : '';
j.async=true;
j.src='https://tagmanager.com/tm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>

</body>
</html></nowiki>

=== Security Problems with requesting Tags ===

The previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. One way to manage this risk is with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This is a secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement:

* technical controls such as only allowing the javascript to access the data layer values, no other DOM element
* restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and javascript code

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<nowiki><script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script></nowiki>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because sometimes you can get '''secure''' but '''not working''' 3rd party code when the vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki>
<html>
<head></head>
<body>
...

<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html></nowiki>

<nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Virtual iframe Containment ==

This technique creates iFrames that run asynchronously in relation to the main page. It also provides its own containment javascript that automates the dynamic implementation of the protected iFrames based on the marketing tag requirements.

== Vendor Agreements ==

You can have the agreement or request for proposal with the 3rd parties require evidence that they have implemented secure coding and general corporate server access security. But in particular you need to determine the monitoring and control of their source code in order to prevent and detect malicious changes to that javascript.

== MarTechSec ==

Marketing Technology Security

This refers to all aspects of reducing the risk from marketing javascript. Controls include

1. Contractual controls for risk reduction; the contracts with any MarTech company should include a requirement to show evidence of code security and code integrity monitoring.

2. Contractual controls for risk transference: the contracts with any MarTech company could include a penalty for serving malicious javascript

3. Technical controls for malicious javascript execution prevention; Virtual Iframes,

4. Technical controls for malicious javascript identification; Subresource Integrity

5. Technical controls including client side javascript malicious behavior in penetration testing requirements

== MarSecOps ==
Marketing Security Operations

This refers to the operational requirements to maintain some of the technical controls. This involves possible cooperation and information exchange between the marketing team, the martech provider and the run or operations team to update the information in the page controls (SRI hash change, changes in pages with SRI), the policies in the Virtual iFrames, tag manager configuration, data layer changes etc.

The most complete controls for any site containing non-trivial marketing tags are -

1. a data layer that calls the marketing server or tag manager APIs , so that only your code executes on your page (inversion of control)

2. Virtual frame Containment.

The MarSecOps requirements to implement technical controls at the speed of change that marketing desires or without a significant number of dedicated resources, can make some controls impractical.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2018-04-18T19:07:07Z

Jweiler: spelling

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Tags, aka marketing tags, analytics tags etc. are small bits of javascript on a web page. They can also be HTML image elements when javascript is disabled. The reason for them is to collect data on the web user actions and browsing context for use by the web page owner in marketing.

Third party vendor javascript tags (hereinafter, '''tags''') can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =
The single greatest risk is a compromise of the third party javascript server, and the injection of malicious javascript into the original tag javascript. This has happened in 2018 and likely earlier.

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for '''tags'''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html></nowiki>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki>
<html>
<head></head>
<body>
...

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or '''tag manager''' site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a '''container''' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

<nowiki>
<html>
<head></head>
<body>
...

<script>(function(w, d, s, l, i){
w[l] = w[l] || [];
w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : '';
j.async=true;
j.src='https://tagmanager.com/tm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>

</body>
</html></nowiki>

=== Security Problems with requesting Tags ===

The previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. One way to manage this risk is with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This is a secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement:

* technical controls such as only allowing the javascript to access the data layer values, no other DOM element
* restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and javascript code

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<nowiki><script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script></nowiki>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because sometimes you can get '''secure''' but '''not working''' 3rd party code when the vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki>
<html>
<head></head>
<body>
...

<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html></nowiki>

<nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Virtual iframe Containment ==

This technique creates iFrames that run asynchronously in relation to the main page. It also provides its own containment javascript that automates the dynamic implementation of the protected iFrames based on the marketing tag requirements.

== Vendor Agreements ==

You can have the agreement or request for proposal with the 3rd parties require evidence that they have implemented secure coding and general corporate server access security. But in particular you need to determine the monitoring and control of their source code in order to prevent and detect malicious changes to that javascript.

== MarTechSec ==

Marketing Technology Security

This refers to all aspects of reducing the risk from marketing javascript. Controls include

1. Contractual controls for risk reduction; the contracts with any MarTech company should include a requirement to show evidence of code security and code integrity monitoring.

2. Contractual controls for risk transference: the contracts with any MarTech company could include a penalty for serving malicious javascript

3. Technical controls for malicious javascript execution prevention; Virtual Iframes,

4. Technical controls for malicious javascript identification; Subresource Integrity

5. Technical controls including client side javascript malicious behavior in penetration testing requirements

== MarSecOps ==
Marketing Security Operations

This refers to the operational requirements to maintain some of the technical controls. This involves possible cooperation and information exchange between the marketing team, the martech provider and the run or operations team to update the information in the page controls (SRI hash change, changes in pages with SRI), the policies in the Virtual iFrames, tag manager configuration, data layer changes etc.

The most complete controls for any site containing non-trivial marketing tags are -

1. a data layer that calls the marketing server or tag manager APIs , so that only your code executes on your page (inversion of control)

2. virtual iframe containment.

The MarSecOps requirements to implement technical controls at the speed of change that marketing desires or without a significant number of dedicated resources, can make some controls impractical.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2018-04-18T19:04:35Z

Jweiler: added sections on Virtual iframe Containment, MarTechSec, MarSecOps

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Tags, aka marketing tags, analytics tags etc. are small bits of javascript on a web page. They can also be HTML image elements when javascript is disabled. The reason for them is to collect data on the web user actions and browsing context for use by the web page owner in marketing.

Third party vendor javascript tags (hereinafter, '''tags''') can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =
The single greatest risk is a compromise of the third party javascript server, and the injection of malicious javascript into the original tag javascript. This has happened in 2018 and likely earlier.

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for '''tags'''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html></nowiki>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki>
<html>
<head></head>
<body>
...

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or '''tag manager''' site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a '''container''' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

<nowiki>
<html>
<head></head>
<body>
...

<script>(function(w, d, s, l, i){
w[l] = w[l] || [];
w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : '';
j.async=true;
j.src='https://tagmanager.com/tm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>

</body>
</html></nowiki>

=== Security Problems with requesting Tags ===

The previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. One way to manage this risk is with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This is a secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement:

* technical controls such as only allowing the javascript to access the data layer values, no other DOM element
* restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and javascript code

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<nowiki><script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script></nowiki>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because sometimes you can get '''secure''' but '''not working''' 3rd party code when the vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki>
<html>
<head></head>
<body>
...

<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html></nowiki>

<nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Virtual iframe Containment ==

This technique creates iFrames that run asynchronously in relation to the main page. It also provides its own containment javascript that automates the dynamic implementation of the protected iFrames based on the marketing tag requirements.

== Vendor Agreements ==

You can have the agreement or request for proposal with the 3rd parties require evidence that they have implemented secure coding and general corporate server access security. But in particular you need to determine the monitoring and control of their source code in order to prevent and detect malicious changes to that javascript.

== MarTechSec ==

Marketing Technology Security

This refers to all aspects of reducing the risk from marketing javascript. Controls include

1. Contractual controls for risk reduction; the contracts with any MarTech company should include a requirement to show evidence of code security and code integrity monitoring.

2. Contractual controls for risk transference: the contracts with any MarTech company could include a penalty for serving malicious javascript

3. Technical controls for malicious javascript execution prevention; Virtual Iframes,

4. Technical controls for malicious javascript identification; Subresource Integrity

5. Technical controls including client side javascript malicious behavior in penetration testing requirements

== MarSecOps ==
Marketing Security Operations

This refers to the operational requirements to maintain some of the technical controls. This involves possible cooperation and information exchange between the marketing team, the martech provider and the run or operations team to update the information in the page controls (SRI hash change, changes in pages with SRI), the policies in the Virtual iFrames, tag manager configuration, data layer changes etc.

The most complete controls for any site containing non-trivial marketing tags are -

1. a data layer that calls the marketing server or tag manager APIs , so that only your code executes on your page (inversion of control)

2. virtual iframes containment.

The MarSecOps requirements to implement technical controls at the speed of change that marketing desires or without a significant number of dedicated resources, can make some controls impractical.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2018-04-18T19:01:51Z

Jweiler: /* MarTechSec */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Tags, aka marketing tags, analytics tags etc. are small bits of javascript on a web page. They can also be HTML image elements when javascript is disabled. The reason for them is to collect data on the web user actions and browsing context for use by the web page owner in marketing.

Third party vendor javascript tags (hereinafter, '''tags''') can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =
The single greatest risk is a compromise of the third party javascript server, and the injection of malicious javascript into the original tag javascript. This has happened in 2018 and likely earlier.

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for '''tags'''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html></nowiki>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki>
<html>
<head></head>
<body>
...

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or '''tag manager''' site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a '''container''' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

<nowiki>
<html>
<head></head>
<body>
...

<script>(function(w, d, s, l, i){
w[l] = w[l] || [];
w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : '';
j.async=true;
j.src='https://tagmanager.com/tm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>

</body>
</html></nowiki>

=== Security Problems with requesting Tags ===

The previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. One way to manage this risk is with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This is a secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement:

* technical controls such as only allowing the javascript to access the data layer values, no other DOM element
* restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and javascript code

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<nowiki><script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script></nowiki>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because sometimes you can get '''secure''' but '''not working''' 3rd party code when the vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki>
<html>
<head></head>
<body>
...

<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html></nowiki>

<nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Vendor Agreements ==

You can have the agreement or request for proposal with the 3rd parties require evidence that they have implemented secure coding and general corporate server access security. But in particular you need to determine the monitoring and control of their source code in order to prevent and detect malicious changes to that javascript.

== MarTechSec ==

Marketing Technology Security

This refers to all aspects of reducing the risk from marketing javascript. Controls include

1. Contractual controls for risk reduction; the contracts with any MarTech company should include a requirement to show evidence of code security and code integrity monitoring.

2. Contractual controls for risk transference: the contracts with any MarTech company could include a penalty for serving malicious javascript

3. Technical controls for malicious javascript execution prevention; Virtual Iframes,

4. Technical controls for malicious javascript identification; Subresource Integrity

5. Technical controls including client side javascript malicious behavior in penetration testing requirements

== MarSecOps ==
Marketing Security Operations

This refers to the operational requirements to maintain some of the technical controls. This involves possible cooperation and information exchange between the marketing team, the martech provider and the run or operations team to update the information in the page controls (SRI hash change, changes in pages with SRI), the policies in the Virtual iFrames, tag manager configuration, data layer changes etc.

The most complete controls for any site containing non-trivial marketing tags are -

1. a data layer that calls the marketing server or tag manager APIs , so that only your code executes on your page (inversion of control)

2. virtual iframes containment.

The MarSecOps requirements to implement technical controls at the speed of change that marketing desires or without a significant number of dedicated resources, can make some controls impractical.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2018-04-18T14:32:17Z

Jweiler: added MarTechSec section

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Tags, aka marketing tags, analytics tags etc. are small bits of javascript on a web page. They can also be HTML image elements when javascript is disabled. The reason for them is to collect data on the web user actions and browsing context for use by the web page owner in marketing.

Third party vendor javascript tags (hereinafter, '''tags''') can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =
The single greatest risk is a compromise of the third party javascript server, and the injection of malicious javascript into the original tag javascript. This has happened in 2018 and likely earlier.

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for '''tags'''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html></nowiki>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki>
<html>
<head></head>
<body>
...

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or '''tag manager''' site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a '''container''' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

<nowiki>
<html>
<head></head>
<body>
...

<script>(function(w, d, s, l, i){
w[l] = w[l] || [];
w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : '';
j.async=true;
j.src='https://tagmanager.com/tm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>

</body>
</html></nowiki>

=== Security Problems with requesting Tags ===

The previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. One way to manage this risk is with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This is a secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement:

* technical controls such as only allowing the javascript to access the data layer values, no other DOM element
* restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and javascript code

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<nowiki><script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script></nowiki>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because sometimes you can get '''secure''' but '''not working''' 3rd party code when the vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki>
<html>
<head></head>
<body>
...

<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html></nowiki>

<nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Vendor Agreements ==

You can have the agreement or request for proposal with the 3rd parties require evidence that they have implemented secure coding and general corporate server access security. But in particular you need to determine the monitoring and control of their source code in order to prevent and detect malicious changes to that javascript.

== MarTechSec ==

Marketing Technology Security

This refers to all aspects of reducing the risk from marketing javascript. Controls include

1. Contractual controls for risk reduction; the contracts with any MarTech company should include a requirement to show evidence of code security and code integrity monitoring.

2. Contractual controls for risk transference: the contracts with any MarTech company could include a penalty for serving malicious javascript

3. Technical controls for malicious javascript execution prevention; Virtual Iframes,

4. Technical controls for malicious javascript identification; Subresource Integrity

5. Technical controls including client side javascript malicious behavior in penetration testing requirements

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2018-04-17T12:28:06Z

Jweiler: added to Vendor Agreements section

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Tags, aka marketing tags, analytics tags etc. are small bits of javascript on a web page. They can also be HTML image elements when javascript is disabled. The reason for them is to collect data on the web user actions and browsing context for use by the web page owner in marketing.

Third party vendor javascript tags (hereinafter, '''tags''') can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =
The single greatest risk is a compromise of the third party javascript server, and the injection of malicious javascript into the original tag javascript. This has happened in 2018 and likely earlier.

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for '''tags'''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html></nowiki>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki>
<html>
<head></head>
<body>
...

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or '''tag manager''' site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a '''container''' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

<nowiki>
<html>
<head></head>
<body>
...

<script>(function(w, d, s, l, i){
w[l] = w[l] || [];
w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : '';
j.async=true;
j.src='https://tagmanager.com/tm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>

</body>
</html></nowiki>

=== Security Problems with requesting Tags ===

The previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. One way to manage this risk is with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This is a secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement:

* technical controls such as only allowing the javascript to access the data layer values, no other DOM element
* restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and javascript code

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<nowiki><script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script></nowiki>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because sometimes you can get '''secure''' but '''not working''' 3rd party code when the vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki>
<html>
<head></head>
<body>
...

<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html></nowiki>

<nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Vendor Agreements ==

You can have the agreement or request for proposal with the 3rd parties require evidence that they have implemented secure coding and general corporate server access security. But in particular you need to determine the monitoring and control of their source code in order to prevent and detect malicious changes to that javascript.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2018-04-17T12:23:35Z

Jweiler: spelling correction

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Tags, aka marketing tags, analytics tags etc. are small bits of javascript on a web page. They can also be HTML image elements when javascript is disabled. The reason for them is to collect data on the web user actions and browsing context for use by the web page owner in marketing.

Third party vendor javascript tags (hereinafter, '''tags''') can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =
The single greatest risk is a compromise of the third party javascript server, and the injection of malicious javascript into the original tag javascript. This has happened in 2018 and likely earlier.

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for '''tags'''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html></nowiki>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki>
<html>
<head></head>
<body>
...

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or '''tag manager''' site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a '''container''' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

<nowiki>
<html>
<head></head>
<body>
...

<script>(function(w, d, s, l, i){
w[l] = w[l] || [];
w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : '';
j.async=true;
j.src='https://tagmanager.com/tm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>

</body>
</html></nowiki>

=== Security Problems with requesting Tags ===

The previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. One way to manage this risk is with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This is a secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement:

* technical controls such as only allowing the javascript to access the data layer values, no other DOM element
* restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and javascript code

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<nowiki><script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script></nowiki>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because sometimes you can get '''secure''' but '''not working''' 3rd party code when the vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki>
<html>
<head></head>
<body>
...

<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html></nowiki>

<nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2018-04-12T17:58:38Z

Jweiler: changed 'the most' to 'a' for data layer

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Tags, aka marketing tags, analytics tags etc. are small bits of javascript on a web page. They can also be HTML image elements when javascript is disabled. The reason for them is to collect data on the web user actions and browsing context for use by the web page owner in marketing.

Third party vendor javascript tags (hereinafter, '''tags''') can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =
The single greatest risk is a compromise of the third party javascript server, and the injection of malicious javascript into the original tag javascript. This has happened in 2018 and likely earlier.

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for '''tags'''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html></nowiki>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki>
<html>
<head></head>
<body>
...

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or '''tag manager''' site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a '''container''' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

<nowiki>
<html>
<head></head>
<body>
...

<script>(function(w, d, s, l, i){
w[l] = w[l] || [];
w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : '';
j.async=true;
j.src='https://tagmanager.com/tm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>

</body>
</html></nowiki>

=== Security Problems with requesting Tags ===

The previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. One way to manage this risk is with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This is a secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement:

* technical controls such as only allowing the javascript to access the data layer values, no other DOM element
* restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and javascript code

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<nowiki><script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script></nowiki>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitimes you can get '''secure''' but '''not working''' 3rd party code when the vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki>
<html>
<head></head>
<body>
...

<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html></nowiki>

<nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2018-04-12T17:55:58Z

Jweiler: aded greatest risk line to Major Risks section.

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Tags, aka marketing tags, analytics tags etc. are small bits of javascript on a web page. They can also be HTML image elements when javascript is disabled. The reason for them is to collect data on the web user actions and browsing context for use by the web page owner in marketing.

Third party vendor javascript tags (hereinafter, '''tags''') can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =
The single greatest risk is a compromise of the third party javascript server, and the injection of malicious javascript into the original tag javascript. This has happened in 2018 and likely earlier.

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for '''tags'''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html></nowiki>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki>
<html>
<head></head>
<body>
...

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or '''tag manager''' site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a '''container''' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

<nowiki>
<html>
<head></head>
<body>
...

<script>(function(w, d, s, l, i){
w[l] = w[l] || [];
w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : '';
j.async=true;
j.src='https://tagmanager.com/tm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>

</body>
</html></nowiki>

=== Security Problems with requesting Tags ===

The previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. One way to manage this risk is with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement:

* technical controls such as only allowing the javascript to access the data layer values, no other DOM element
* restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and javascript code

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<nowiki><script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script></nowiki>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitimes you can get '''secure''' but '''not working''' 3rd party code when the vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki>
<html>
<head></head>
<body>
...

<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html></nowiki>

<nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-08-31T02:42:35Z

Jweiler: /* Security Problems with requesting Tags */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Tags, aka marketing tags, analytics tags etc. are small bits of javascript on a web page. They can also be HTML image elements when javascript is disabled. The reason for them is to collect data on the web user actions and browsing context for use by the web page owner in marketing.

Third party vendor javascript tags (hereinafter, '''tags''') can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for '''tags'''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html></nowiki>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki>
<html>
<head></head>
<body>
...

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or '''tag manager''' site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a '''container''' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

<nowiki>
<html>
<head></head>
<body>
...

<script>(function(w, d, s, l, i){
w[l] = w[l] || [];
w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : '';
j.async=true;
j.src='https://tagmanager.com/tm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>

</body>
</html></nowiki>

=== Security Problems with requesting Tags ===

The previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. One way to manage this risk is with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement:

* technical controls such as only allowing the javascript to access the data layer values, no other DOM element
* restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and javascript code

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<nowiki><script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script></nowiki>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitimes you can get '''secure''' but '''not working''' 3rd party code when the vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki>
<html>
<head></head>
<body>
...

<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html></nowiki>

<nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-08-31T02:39:22Z

Jweiler: /* Subresource Integrity */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Tags, aka marketing tags, analytics tags etc. are small bits of javascript on a web page. They can also be HTML image elements when javascript is disabled. The reason for them is to collect data on the web user actions and browsing context for use by the web page owner in marketing.

Third party vendor javascript tags (hereinafter, '''tags''') can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for '''tags'''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html></nowiki>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki>
<html>
<head></head>
<body>
...

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or '''tag manager''' site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a '''container''' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

<nowiki>
<html>
<head></head>
<body>
...

<script>(function(w, d, s, l, i){
w[l] = w[l] || [];
w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : '';
j.async=true;
j.src='https://tagmanager.com/tm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>

</body>
</html></nowiki>

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement:

* technical controls such as only allowing the javascript to access the data layer values, no other DOM element
* restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and javascript code

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<nowiki><script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script></nowiki>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitimes you can get '''secure''' but '''not working''' 3rd party code when the vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki>
<html>
<head></head>
<body>
...

<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html></nowiki>

<nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-08-31T02:14:19Z

Jweiler: /* Introduction */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Tags, aka marketing tags, analytics tags etc. are small bits of javascript on a web page. They can also be HTML image elements when javascript is disabled. The reason for them is to collect data on the web user actions and browsing context for use by the web page owner in marketing.

Third party vendor javascript tags (hereinafter, '''tags''') can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for '''tags'''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html></nowiki>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki>
<html>
<head></head>
<body>
...

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or '''tag manager''' site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a '''container''' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

<nowiki>
<html>
<head></head>
<body>
...

<script>(function(w, d, s, l, i){
w[l] = w[l] || [];
w[l].push({'tm.start':new Date().getTime(), event:'tm.js'});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : '';
j.async=true;
j.src='https://tagmanager.com/tm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'TM-FOOBARID');</script>

</body>
</html></nowiki>

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement:

* technical controls such as only allowing the javascript to access the data layer values, no other DOM element
* restricting the tag types deployed on a host site, e.g. disabling of custom HTML tags and javascript code

The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company. It also can be two-factor authentication.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<nowiki><script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script></nowiki>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki>
<html>
<head></head>
<body>
...

<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html></nowiki>

<nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>

<script src="https://analytics.vendor.com/v1.1/script.js"></script>

</body>
</html></nowiki>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

Boston

2016-06-08T13:39:25Z

Jweiler: /* Boston OWASP Chapter Leaders */

{{Chapter Template|chaptername=Boston|extra=Follow @OWASPBOSTON on Twitter. The chapter leader is [mailto:jim.weiler@owasp.org Jim Weiler]. The Boston chapter is grateful for support from:

|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Boston|emailarchives=http://lists.owasp.org/pipermail/owasp-Boston}}

== Chapter Meetings --- Our Tenth Year ==

We now use [http://www.meetup.com/owaspboston/ meetup] to organize meetings.

We usually meet the FIRST WEDNESDAY of EVERY MONTH (Unless a speaker can only present another night), 6:30 to 9 pm.

Everyone is welcome to come to any meeting, there is no signup or joining criteria, just come if it sounds interesting. Feel free to sign up to the [http://lists.owasp.org/mailman/listinfo/owasp-boston OWASP Boston mailing list]. This list is very low volume (2 - 3 emails/month); it is used to remind people about each monthly meeting, inform about local application security events and special chapter offers.


Most meetings are held at [http://www.akamai.com/html/about/locations.html Akamai] at 150 Broadway
Cambridge, MA 02142 (aka 8 Cambridge Center).

=== Upcoming Training ===

'''July 18th & 19th 2016''' - Waltham - [https://www.regonline.com/Register/Checkin.aspx?EventID=1844420 Register]

Location: Constant Contact [https://www.google.com/maps/place/Constant+Contact/@42.4185837,-71.2586063,15z/data=!4m5!3m4!1s0x0:0xbcaab68dd299cf76!8m2!3d42.4185837!4d-71.2586063 Map] location: 1601 Trapelo Rd, Waltham, MA 02451

8AM to 5PM '''Practical Web Application Penetration Testing - PWAPT'''

<p>This course provides customized training on the latest open source tools and manual techniques for performing end-to-end web application penetration testing engagements. After a quick overview of the penetration testing methodology, the instructor will lead students through the process of testing and exploiting a target web application using the techniques and approaches developed from a career of real world application penetration testing experiences. Students will be introduced to the best open source tools currently available for the specific steps of the methodology, including Burp Suite Pro, and taught how to integrate these tools with manual testing techniques to maximize effectiveness. A major goal of this course is teaching students the glue that brings the tools and techniques together to successfully perform a web application penetration test from beginning to end, an oversight in most web application penetration testing courses.</p>

<p>The majority of the course will be spent performing an instructor led, hands-on web application penetration test against a target application built specifically for this class using a modern technology stack (Python Flask) and including real vulnerabilities as encountered in the wild. No old-school vanilla PHP stuff here folks. Students won’t be given overly simplistic steps to execute independently. Rather, at each stage of the test, the instructor will present the goals that each testing task is to accomplish and perform the penetration test in front of the class while students do it on their own machine. Primary emphasis of these instructor led exercises will be placed on how to integrate the tools with manual testing procedures to improve the overall work flow. This experience will help students gain the confidence and knowledge necessary to perform web application penetration tests as an application security professional.</p>

<p>PWAPT is a PortSwigger preferred [https://portswigger.net/training Burp Suite Training] course. PWAPT students will learn basic and advanced usage techniques for Burp Suite Pro, as well as discover obscure functionality hidden within the vast capabilities of the tool. Students will also receive a 2 week trial license for Burp Suite Pro to use during the course.</p>

<h4 id="outline">Outline</h4>

<p>Day 1:</p>

<ul>
<li>Methodology</li>
<li>Reconnaissance</li>
<li>Mapping</li>
<li>Automated Discovery</li>
<li>Manual Discovery</li>
</ul>

<p>Day 2:</p>

<ul>
<li>Manual Discovery (cont.)</li>
<li>Exploitation</li>
<li>Web Services</li>
</ul>

<h4 id="technical-requirements">Technical Requirements</h4>

<ul>
<li>Laptop with at least two (2) USB ports.</li>
<li>Latest VMware Player, VMware Workstation, or VWware Fusion installed. Other virtualization software such as Parallels or VirtualBox will probably work if the attendee is familiar with its functionality. However, VMware Player should be prepared as a backup.</li>
<li>Ability to disable all security software on their laptop such as Antivirus and/or firewalls (Administrator).</li>
<li>At least twenty (20) GB of hard drive space.</li>
<li>At least four (4) GB of RAM.</li>
</ul>

Tim (lanmaster53) Tomes

Christian, father, husband, veteran, code slinger, aspiring difference-maker and hacking enthusiast.

=== Upcoming Meetings ===

'''June 8, 2016''' - Burlington - [http://www.meetup.com/owaspboston/events/230842887/ Meetup]

Location: [https://www.google.com/maps/place/5+Wall+St,+Burlington,+MA+01803/@42.4877956,-71.1904085,17z/data=!3m1!4b1!4m5!3m4!1s0x89e3758106c4cb55:0xc155e97a6d34883e!8m2!3d42.4877956!4d-71.1882198?hl=en Demandware] at 5 Wall St., Burlington, MA

6-6:30 '''News, announcements, job postings, etc. '''

6:30-7 '''Introduction to SQL Injection - Jim Weiler'''

7:00 '''Computer Science Curricula’s Failure - What Should We Do Now?''' - '''Ming Chow & Roy Wattanasin'''

We are still facing the same security vulnerabilities from over a decade ago. The problems are not going away anytime soon and a reason is because Computer Science curricula are still churning out students who are not even exposed to security. This talk will address the lack of emphasis on information security in Computer Science curricula, how CS curricula have an obligation, how to gradually fix the problem by integrating security into many Computer Science undergraduate and graduate classes, and success stories from students. This talk will also discuss what Tufts and Brandeis are currently working on to further address the security education problem by creating a joint cyber security and policy program that spans multiple departments. Additional points and feedback from the audience are encouraged to help with the issue. All are encourage to attend to submit your feedback to help!

Presenters:

Ming Chow - @0xmchow

Ming Chow is a Senior Lecturer at the Tufts University Department of Computer Science. His areas of work are in web and mobile engineering and web security. He was a web application developer for ten years at Harvard University. Ming has spoken at numerous organizations and conferences including the High Technology Crime Investigation Association - New England Chapter (HTCIA-NE), the Massachusetts Office of the Attorney General (AGO), John Hancock, OWASP, InfoSec World, DEF CON, Intel, SOURCE Conference, and BSides Boston. He was a mentor for a Proving Ground speaker at BSides Las Vegas in 2014 and 2015.

Roy Wattanasin - @wr0

Roy Wattanasin is an adjunct faculty at Brandeis University in both the Health and Medical Informatics and Information Security graduate programs. He spends most of his time leading, teaching and developing information security programs, finding vulnerabilities, performing incident response and working on many projects. Roy has spoken at many conferences including RSA, ISSA International, Source Conference, Braintank, Cyber Security World, OWASP and the Security BSides conferences. He is also a healthcare information security professional. He was a mentor for a Proving Ground speaker at BSides Las Vegas in 2015.

'''May 4, 2016''' - Cambridge - [http://www.meetup.com/owaspboston/events/229788205/ Meetup]

Location: Slightly different [http://www.akamai.com/html/about/locations.html Akamai] location: 90 Broadway, Cambridge, MA 02142 between Meadhall and the Mariott

6:30 '''News, OWASP tools, documents review'''

7:00 '''The ABCs of Source-Assisted Web Application Penetration Testing With OWASP ZAP''' - '''Dan Cornell'''

There are a number of reasons to use source code to assist in web application penetration testing such as making better use of penetration testers’ time, providing penetration testers with deeper insight into system behavior, and highlighting specific sections of so development teams can remediate vulnerabilities faster. Examples of these are provided using the open source ThreadFix plugin for the OWASP ZAP proxy and dynamic application security testing tool. These show opportunities attendees have to enhance their own penetration tests given access to source code.

This presentation covers the “ABCs” of source code assisted web application penetration testing: covering issues of attack surface enumeration, backdoor identification, and configuration issue discovery. Having access to the source lets an attacker enumerate all of the URLs and parameters an application exposes – essentially its attack surface. Knowing these allows pen testers greater application coverage during testing. In addition, access to source code can help to identify potential backdoors that have been intentionally added to the system. Comparing the results of blind spidering to a full attack surface model can identify items of interest such as hidden admin consoles or secret backdoor parameters. Finally, the presentation examines how access to source code can help identify configuration settings that may have an adverse impact on the security of the deployed application.

Dan Cornell is a globally recognized application security expert, Dan Cornell holds over 15 years of experience architecting, developing and securing web-based software systems. As the Chief Technology Officer and a Principal at Denim Group, Ltd., he leads the technology team to help Fortune 500 companies and government organizations integrate security throughout the development process. He is also the original creator of ThreadFix, Denim Group's industry leading application security program management platform. Cornell was Principal Investigator as Denim Group researched and developed the Hybrid Analysis Mapping (HAM) technology that lies at the heart of ThreadFix, through a Small Business Innovation Research (SBIR) contract with the Department of Homeland Security's Science and Technology Directorate.

More information at: http://www.denimgroup.com/about_team_dan.html

'''April 6, 2016''' - Cambridge - [http://www.meetup.com/owaspboston/events/229223967/ Meetup]

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 150 Broadway, Cambridge, MA 02142 (aka 8 Cambridge Center)

6:30 '''News, OWASP tools, documents review'''

7:00 '''Runtime Application Self-Protection (RASP) Tools''' - '''Kunal Anand'''

This talk will highlight the latest in AppSec and dive into a different kind of solution called Runtime Application Self-Protection (RASP). We'll also explore a new methodology called language theoretic security (LANGSEC) and explain how it can outperform existing approaches like pattern matching, regular expressions, etc. This talk will lay the foundation via informal and formal theory how lexers, tokenizers and parsers work. We’ll move onto constructing an open source toolchain to analyzing data and exploring interactive data visualizations. Along the way, we’ll cover performance tradeoffs and discuss the challenges of modern application security.

Kunal Anand is the co-founder and CTO of Prevoty, a runtime application security platform. Prior to that, he was the Director of Technology at the BBC Worldwide, overseeing engineering and operations across the company’s global Digital Entertainment and Gaming initiatives. Kunal also has several years of experience leading security, data and engineering at Gravity, MySpace and NASA’s JetPropulsion Laboratory. His work has been featured in Wired Magazine and Fast Company. Kunal received a B.S. from Babson College.

=== Past Meetings ===

'''March 16, 2016''' - Burlington - [http://www.meetup.com/owaspboston/events/229156529/ Meetup]

Location: Demandware, Burlington.

6:00 '''News, OWASP tools, documents review'''

6:30 '''Software Security by the Numbers''' - '''Chris Eng'''

Deep dive into data we’ve collected about the state of software security in 2016
* Based on scans of 200,000+ applications over an 18-month period
* How different industries and programming languages compare to one another
* Vulnerability remediation habits and patterns
* Three characteristics of a successful AppSec program

Chris Eng is vice president of research at Veracode. In this role, he leads the team responsible for integrating security expertise into all aspects of Veracode’s technology. Throughout his career, he has led projects breaking, building, and defending web applications and commercial software for some of the world’s largest companies. Chris is a frequent speaker at premier industry conferences, where he has presented on a diverse range of topics, including cryptographic attacks, agile security, mobile application security, and security metrics. He has been interviewed by Bloomberg, Fox Business, CBS, and other media outlets worldwide.

'''January 26, 2016''' - Waltham - [http://www.meetup.com/owaspboston/events/228202040/ Meetup]

Location: Constant Contact, Waltham. Trapelo Rd. exit from Rt. 128, toward Lincoln. The parking lot entrance is on the right, at the first traffic light. Drive around to the front of the office complex, facing the highway. Enter under the clock tower. Park in the front of the building and enter in the main building lobby, continue down the hallway and you will see the innovation center, enter in the large glass doors.

7:00 '''News, OWASP tools, documents review'''

7:20 '''What Security Testing Tools Miss'''

Black Duck Software presents - Static analysis, dynamic analysis, and other testing tools are all essential weapons against adversaries. But for the 80%+ of companies worldwide that use open source software in their application development these tools are ineffective in identifying and mitigating open source security risks . This presentation will cover:

The value of static and dynamic tools, and where they best fit in the Secure Development Lifecycle

Why these tools are not useful in identifying known vulnerabilities in open source components

Controls development and security professionals can deploy to select, detect, manage and monitor open source for existing and newly disclosed vulnerabilities

Food will be provided by Constant Contact.

'''November 2015''' - Cambridge - [http://www.meetup.com/owaspboston/events/226394218/ Meetup]

When: Wednesday, November 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 150 Broadway
Cambridge, MA 02142 (aka 8 Cambridge Center)

6:30 '''News, views, announcements, conversation'''

7:00 '''Interactive Discussions (Come and ask your questions!)'''

Attendee interaction is always mentioned as a high value at meetings and was great at the MetroWest meetings, so we're doing that at Akamai this month. Some discussion starters so far: SSL certificate impacts from CA/Browser alliance decisions and SHA1 weakness; mutual (client) SSL, javascript client and server side; what the heck is threat intelligence, dev ops and faster secure SDLC.

'''July 2015''' - Metrowest

When: Wednesday, July 20, 7:00 pm

Location: Constant Contact, Innovation Center, Reservoir Place, 1601 Trapelo Road, Waltham, MA 02451

7:00 '''News, views, announcements, conversation'''

7:30 '''Access in Maliceland - Risk Based Access Control''' - '''Gunnar Peterson'''

John Lambert observed attackers win because while defenders think in lists, attackers think in graphs. Access control systems divide the system a priori into secure and insecure states. But that’s only worth the paper its printed on. A Attackers see the system as it is, for attackers, the access control scheme is the beginning of the game not the end. Determined attackers seek out access control models and then find holes that they can leverage. Access control systems that purport to protect the system are built on assumptions from which reality diverges. Application security needs a new approach to access control- adding feedback loops for risk based decisions, fine-grained, dynamic access control.

Security is a business with a very long list of issues and requirements. The spreadsheets are miles long. This makes it essential to find reusable solution patterns that can address multiple problems.This presentation looks at both medium term improvements and code examples to improve access control decisions and overall security today

Gunnar Peterson ([https://twitter.com/oneraindrop @oneraindrop]) focuses on security architecture consulting and training. Experience includes Associate Editor for IEEE Security & Privacy Journal, a Microsoft MVP for App security, an IANS Research Faculty member, a Securosis Contributing Analyst, and a Visiting Scientist at Carnegie Mellon Software Engineering Institute. He maintains a popular information security blog at http://1raindrop.typepad.com.

'''July 2015''' - Cambridge

When: Wednesday, July 8, 6:30 pm ''NOTE: It's the second Wednesday this month.''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''Interactive Discussions (Come and ask your questions!)'''

'''June 2015'''

When: Wednesday, June 3, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''Put Down the Megaphone: Effective Security Advocacy Without the Shouting''' - '''Darren Meyer'''

10 years’ experience in the InfoSec community--including work with organizations in many verticals, in sizes ranging from startups to Fortune 50 enterprises, leading Application Security teams, building and delivering security instruction to developers, managers, and InfoSec professionals—has taught me the importance of crafting advocacy for different audiences. In this talk, I share my experiences in learning to be an effective advocate with three key audiences: developers, management, and non-technical staff.

Darren is an Application Security advocate and researcher, technology hobbyist, and maker. He loves to learn, teach, nerd out, and inflict terrible puns on people. His background includes logistics, software development, and an assortment of information security roles including leading AppSec programs and professional security instruction targeting developers, managers, and InfoSec professionals.

'''May 2015'''

When: Wednesday, May 6, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''How the crowd is discovering critical vulns missed by traditional methods''' - '''Leif Dreizler'''

State of the art security programs are turning to bug bounties to leverage a vast array of skill-sets and knowledge. Learn why these programs work, when to deploy them, and how you can bring these new application security testing capabilities into your own organization. The speaker will discuss real world examples from bug bounties and focus on cases where business logic flaws and high priority vulnerabilities were found ... even with existing security testing processes in place.

Attendees will learn:

Testing methods deployed by our crowd that help them find bugs the scanners miss

Examples of the high quality of bugs our crowd is finding, including P1'sTrends which vulnerability types are found most often and whyWhat is the ROI on the pay for performance modelWhere does the SDLC merge into crowdsourced testing

Leif Dreizler is a Senior Security Engineer at Bugcrowd, the innovator in crowdsourced security testing for the enterprise. Prior to joining Bugcrowd, Leif was a Senior Application Security Engineer at Redspin, performing application security assessments. During his time at Redspin he also served as the Application Team Lead, liaising with clients at the engineering and sales level. He has also made minor contributions to the Firebug project. Leif attended the University of California, Santa Barbara where he studied Computer Science. Leif recently spoke to the NYC Security Meet-up group.

'''April 2015'''

When: Wednesday, April 1, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

Jim Weiler Will show some actual examples and patterns of SQL Injection attempts

7:00 '''Are You An Imposter? Me too!''' - '''Patrick Laverty'''

Many people in the information security field feel like a fraud, or an imposter. In reality, we often know far more, and are capable of far more than we believe we do. There is so much to know and we constantly hear about the latest groundbreaking research done by others, which makes us feel less important or worthy. Let’s talk about what Imposter Syndrome is, its prevalence, and then we can start to realize just how capable we are and go forward with the confidence in the field.

'''March 2015'''

When: Wednesday, March 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News, views, announcements, conversation'''

7:00 '''Prioritizing Web Application Vulnerabilities – A Hacker’s Perspective''' - '''Nick Silver'''

The best application risk models capture not only the technical risk factors, but also the business context in which an asset lives. Traditionally, this is done by auditing application owners on an array of questions in order to properly classify the asset and its data – but that takes time which could be better spent elsewhere. We interviewed dozens of hackers and asked them which vulnerabilities they would look for first depending on the type of attack they wanted to carry out. We’ll walk through several examples of how to use this data as a shortcut means for prioritizing risk without the need for any pesky audit questionnaires.

Nick Silver is a Senior Solutions Architect with WhiteHat Security. He is responsible for translating business requirements into technical ones and assisting businesses in implementing web security programs. Previously, Nick led a team in WhiteHat’s Threat Research Center where they were responsible for testing more than 2,000 of their customers’ websites for vulnerabilities.

'''February 2015'''

When: Wednesday, February 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News review, announcements''' - '''Jim Weiler'''

7:00 '''Incident Response and Web Application Security - Stories from the Trenches''' - '''Fred House and Joe Ceirante'''

Mandiant has conducted numerous incident response engagements throughout its history, including a record number of 200 incidents in 2014. Mandiant consultants Fred House and Joe Ceirante will discuss case studies and trends Mandiant has observed in relation to web application security.

Topics will include the types of threat actors that target web applications, the techniques they use to compromise web applications, and the activities they perform once inside the network. Techniques for detecting and mitigating web compromises will also be reviewed. All content will be derived from the real-world compromises that Mandiant has investigated.

'''January 2015'''

When: Wednesday, January 7, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News review, risk analysis of Poodle''' - '''Jim Weiler'''

7:00 '''How a Hacker Views Your Web Site''' - '''Patrick Laverty'''

''The most popular presentation of BASC 2014''

As defenders, we have to be right 100% of the time where an attacker only needs to be right once. The attack surface of a modern web site is incredibly large and we need to be aware of all of it. Additionally, individual attacks may not always be effective but sometimes using them together can gain the desired effect. In this talk, we’ll take a look at the whole attack surface for a typical web site and the various ways that an attacker will use to compromise a site.

'''December 2014'''

When: Wednesday, December 3, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 '''News and Views You Can Use and Abuse''' - '''Jim Weiler'''

* Some thoughts and analysis on some current app security news and other stuff
* Adobe password breach
* Reducing Web Application Firewall SQL injection false positives

7:15 '''Swift and Security''' - '''Ming Chow'''

Apple is pushing its new programming language Swift for iOS development and for many good reasons. This talk will discuss what the language has right in terms of security, the old and new security pitfalls, and what developers need to be aware of moving forward with using the new language. The fact to the matter is, iOS isn't going away, iOS developers will need to learn and use Swift, and there will be a big rush of Swift-based apps: we might as well learn how to do it right the first time around.

Ming Chow is an Instructor at the Department of Computer Science, Tufts University. Ten years of web development experience.
Specialties: Web and Mobile Development, Web and Mobile Security

'''July 2014'''

Topics: '''Grails Security''' and '''Validating Cross-Site Scripting Vulns with xssValidator'''

Presenters: '''Cyrus Malekpour''' and '''John Poulin'''

When: Tuesday, July 8, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic 1: ''Grails Security''

Grails is a framework developed for Groovy in the vein of Rails for Ruby. It provides a lot of features for web app security, but does it do enough? What might you need to implement yourself, and what might be provided? This presentation will discuss tips on securing Grails applications, including tools that the framework provides by default for security. It'll also discuss several shortcomings in the current toolset, and how you can avoid them.

Cyrus Malekpour (@cmalekpour) is currently interning at nVisium, working on web app development and security. He's currently an undergraduate student at the University of Virginia, where he's studying computer science with an emphasis on security and backend development.

Topic 2: ''Validating Cross-Site Scripting Vulns with xssValidator''

xssValidator is a tool developed to automate the testing and validation of Cross-Site Scripting (xss) vulnerabilities within web applications. Automated scanners tend to report large amounts of false-positives, and as consultants we're forced spending our time trying to verify these findings. xssValidator leverages scriptable web-browsers such as PhantomJS and Slimer.js to automatically validate these findings.

John Poulin is an application security consultant for nVisium who specializes in web application security. He worked previously as a web developer and software engineer that focused on building multi-tier web applications. When he's not hacking on web apps, John spends his time building tools to help him hack on web apps! You can find him on twitter: @forced_request and on myspace: REDACTED.

'''June 2014'''

Topic: '''Training: SQL Injection and the OWASP Zed Attack Proxy (ZAP)'''

Presenters: '''Rob Cheyne and Jim Weiler'''

When: Wednesday, June 4, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

6:30 - general networking, news discussion, announcements.

7:00 - main presentations

The June 4th meeting will be the second in our series of 2014 training meetings. Rob Cheyne will continue explaining and exploring SQL Injection by conducting an actual injection attack.

This will be a demo-based discussion to get into the mindset of an attacker, and show how an attacker goes after a site. Demo will include:

* BurpProxy demo
* Common authentication flaws
* SQL Injection Demo that shows the process and how it builds to a full compromise

'''Rob Cheyne''' is currently CEO of Big Brain Security. In addition to security consulting for Fortune 500 customers, he was the author of LC4, a version of the award-winning L0phtCrack password auditing tool, and he also worked on the code scanning technology that was eventually spun off as Veracode. Rob was at @stake from the very first customer all the way through to the $50M acquisition by Symantec.

'''Jim Weiler''' will introduce the OWASP Zed Attack Proxy (ZAP). This is a very powerful free OWASP intercepting proxy that lets you see, analyze, change, replay etc. every browser request and response, analyze your session, scan and attack web sites, save the results and run reports. We can't cover all the functionality but we'll show some practical tips and techniques.

Pizza, salad and soda courtesy of Akamai

'''March 2014'''

Topic: '''Training: SQL Injection, WebGoat, Cross Site Request Forgery'''
Presenter: '''Benjamin Lerner'''
When: Wednesday, March 5, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

There will be three training sessions:

One will be on SQL Injection - intro, detection, prevention, scanning and false positives. This is the most serious web application vulnerability.

The second will be on OWASP WebGoat. WebGoat is a deliberately insecure web application maintained by OWASP designed to teach web application security lessons. You can install and practice with WebGoat in either J2EE or in ASP.NET. In each lesson, users must demonstrate their understanding of a security issue by exploiting a real vulnerability in the WebGoat applications. There are hints and 39 different lesson plans on various vulnerabilities and technologies. We won't cover all of them of course!

The third will be on Cross Site Request Forgery - not a hack really, it's just the way the web works. But it causes apps to do legitimate things that you didn't ask them to do.

Pizza and drinks provided by Akamai.

'''January 2014'''

When: Wednesday, January 8, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic: '''JavaScript Verification: From Browsers to Pages'''

Modern web browsers implement a "private browsing" mode that is intended to leave behind no traces of a user's browsing activity on their computer. This feature is in direct tension with support for *extensions*, which let users add third-party functionality into their browser. I will discuss the scope of this problem, present our approach to verifying extensions' compliance with private browsing mode, and sketch our findings on several real, third-party extensions. I will then briefly describe the toolkit underlying our approach, and end with a sketch of a newer project, adapting this approach to the very different-seeming problem of statically catching errors when using the jQuery library.

Presenter: '''Benjamin Lerner'''

Benjamin Lerner has just completed a post-doctoral research position in the PLT group at Brown University, and is now a lecturer at Northeastern University. His research examines the challenges of analyzing client-side web programming, from the behavior of web pages down through the semantics of the browser. He received a PhD in Computer Science from the University of Washington in 2011, building a platform to analyze conflicts between browser extensions, and a B.S. in Computer Science and Mathematics from Yale University.

'''November 2013'''

When: Wednesday, November 6, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic: '''Attacking iOS Applications'''

Slides: [http://www.slideshare.net/kfosaaen/i-os-gcandpb On slideshare]

This presentation will cover the basics of attacking iOS applications (and their back ends) using a web proxy to intercept, modify, and repeat HTTP/HTTPS requests. (The proxy used during research was Burp; however, any HTTP intercepting proxy such as OWASP ZAP could be used) From setting up the proxy to pulling data from the backend systems, this talk will be a great primer for anyone interested in testing iOS applications at the HTTP protocol level. There will be a short (2 minute) primer on setting up the intercepting proxy, followed by three practical examples showing how to intercept data headed to the phone, how to modify data heading to the application server, and how to pull extra data from application servers to further an attack. All of these examples will focus on native iOS apps (Game Center and Passbook) and/or functionality (Passbook Passes).

Presenter: '''Karl Fosaaen'''

Karl is a senior security consultant at NetSPI. This role has allowed Karl to work in a variety of industries, including financial services, health care, and hardware manufacturing. Karl specializes in network and web application penetration testing. In his spare time, Karl helps out as an OPER at THOTCON and a swag goon at DEF CON.

'''October 2013'''

When: Wednesday, October 2, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Topic: '''Abusing NoSQL Databases'''

The days of selecting from a few SQL database options for an application are over. There is now a plethora of NoSQL database options to choose from: some are better than others for certain jobs. There are good reasons why developers are choosing them over traditional SQL databases including performance, scalabiltiy, and ease-of-use. Unfortunately like for many hot techologies, security is largely an afterthought in NoSQL databases. This short but concise presentation will illustrate how poor the quality of security in many NoSQL database systems is. This presentation will not be confined to one particular NoSQL database system. Two sets of security issues will be discussed: those that affect all NoSQL database systems such as defaults, authentication, encryption; and those that affect specific NoSQL database systems such as MongoDB and CouchDB. The ideas that we now have a complicated heterogeneous problem and that defense-in-depth is even more necessary will be stressed. There is a common misconception that SQL injection attacks are eliminated by using a NoSQL database system. While specifically SQL injection is largely eliminated, injection attack vectors have increased thanks to JavaScript and the flexibility of NoSQL databases. This presentation will present and demo new classes of injection attacks. Attendees should be familiar with JavaScript and JSON.

Presenter: '''Ming Chow'''

Ming Chow (@tufts_cs_mchow) is a Lecturer at the Tufts University Department of Computer Science. His areas of work are in web and mobile engineering and web security. He teaches courses largely in the undergraduate curriculum including the second course in the major sequence, Web Programming, Music Apps on the iPad, and Introduction to Computer Security. He was also a web application developer for ten years at Harvard University. Ming has spoken at numerous organizations and conferences including the High Technology Crime Investigation Association - New England Chapter (HTCIA-NE), the Massachusetts Office of the Attorney General (AGO), John Hancock, OWASP, InfoSec World (2011 and 2012), DEF CON 19 (2011), the Design Automation Conference (2011), Intel, and the SOURCE Conference (Boston 2013). Ming's projects in information security include building numerous CTF challenges, Internet investigations, HTML5 and JavaScript security, and Android forensics.

'''September 2013 - Joint Meeting with [http://www.meetup.com/Boston-cloud-services/ Boston Cloud Services]'''

When: Tuesday, September 10, 6 pm

Location: Microsoft NERD Center ''(not our usual location)''

'''Note: This is a joint meeting. Please register at [http://www.meetup.com/Boston-cloud-services/ the Boston Cloud Services meetup page] if you plan to attend.'''

There will be two presentations at this meeting:

Topic: '''People Centric Security (PCS)'''

Presenter: '''Nick Stamos'''

People Centric Security (PCS) is a new security model, presented as part of Gartner's Maverick Research 2 year ago. PCS is well suited for Cloud Business/Consumer services such as Dropbox, Google Drive, SkyDrive, etc. PCS enables users to have what they desire, and provides enterprises what they require for data governance and compliance. Nick Stamos co-founded his fourth company, nCrypted Cloud in July of 2012. His past startups include Verdasys, Phase Forward (IPO FY2004, $685M Oracle Acquisition 2010), and Amulet. He studied at Tufts University where he received a BSEE and MSEE.

Topic: '''SSL Certs'''

Presenter: '''Jim Weiler'''

Practical experiences with issuing and risk assessing SSL certs for enterprise applications on a cloud provider: who creates the CSR, how do you protect the private key on the cloud server, certs on cloud provider managed load balancers vrs 3rd party managed app servers, roles and responsibilities of cloud IT, 3rd party developer IT, enterprise IT and service providers. Jim Weiler is Application Security Architect at Starwoods Hotels and the Chapter Leader of OWASP Boston.

'''July 2013 - Doubleheader!'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, July 10, 6:30 pm

Topic: '''RailsGoat'''

Presented by: '''Ken Johnson'''

Abstract: While working to secure rails applications in a truly Agile development environment, it became clear that the Rails and Ruby ecosystem needed attention from the security community in the form of free and open training, and the events that have transpired within the last few months have only reinforced that belief. [http://railsgoat.cktricky.com/ RailsGoat] is an attempt to bring attention to both the problems that most frequently occur in Rails as well as the solutions for remediation. To accomplish this, we've built a vulnerable Rails application that aligns with the OWASP Top 10 and can be used as a training tool for Rails-based development shops.

Topic: '''PhoneGap on Android'''

Presented by: '''Jack Mannino'''

Abstract: PhoneGap is a widely used framework that allows developers to rapidly build cross-platform mobile applications using HTML5, JavaScript, and CSS. Using PhoneGap plugins, developers can call native platform APIs from browser-like applications using JavaScript. This approach introduces vulnerabilities that are not typically as prevalent within native Android applications, warranting a fresh look at the way we view mobile applications. In this presentation, we will take a deep look at the Android implementation of the framework and we will examine the overall attack surface for applications. Real-world examples of vulnerable applications will be demonstrated as well in order to provide context, entertainment, and enjoyment.

About the Speakers:

Ken Johnson is the former Manager of LivingSocial.com's application security team where he built their security program before leaving for his true home as the CTO of nVisium Security, a VA-based application security company. Ken is the primary developer of the Web Exploitation Framework and contributes to other open source application security projects as often as time permits. He has spoken at AppSec DC 2010 and 2012, OWASP NoVA and Phoenix chapters, Northern Virginia Hackers Association (NoVAH) and is a contributor to the Attack Research team.

Jack Mannino is the CEO of nVisium Security, a VA-based application security company. At nVisium, he helps to ensure that large corporations, government agencies, and software startups have the tools they need to build and maintain successful security initiatives. He is an active Android security researcher/tinkerer, and has a keen interest in identifying security issues and trends on a large scale. Jack is a leader and founder of the OWASP Mobile Security Project. He is the lead developer for the OWASP GoatDroid project, and is the chairman of the OWASP Northern Virginia chapter.

'''June 2013'''

Topic: '''We see the future…and it isn’t pretty'''

Presented by: '''Andrea Mulligan, Sr. Director at Veracode'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, June 5, 6:30 pm

In this session Andrea presents research findings from the State of Software Security Report, which offers a before the breach look at security by examining the flaws commonly found in applications of all kinds. She will also examine what the research findings mean for security, predict how these flaws could cause history to repeat itself, and discuss how security pros can help change the future.

'''May 2013'''

Topic: '''Systems Thinking + Web Security'''

Presented by: '''Akamai'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, May 1, 6:30 pm

Akamai will present on ‘Systems Thinking + Web Security’. There will also be an audience review exercise facilitated by the Akamai presenters. This is a great chance to hear some interesting perspectives on web security from Akamai, who handles about one third of all internet traffic.

'''April 2013'''

Topic: '''Go Fast. Be Secure: Effectively Govern the Use of Open Source Components Throughout the SDLC'''

Presented by: '''Sonotype'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

When: Wednesday, April 3, 6:30 pm

* Open Source Software (OSS) Component supply chain complexities and realities. Open source is constantly changing and knowing the version in your software, as well as the current version history of the component (how do you show an auditor you are using a current version) is important.
* Open Source Consumption Patterns from the Central Repository. Which versions are the most popular can tell you which versions are the most stable, useful, secure etc.
* OWASP Top 10 (A9) - Using Components with Known Vulnerabilities. To decide on the risk of OSS components with vulnerabilities, you need to know the vulnerabilities, their severity and which components they occur in as well as where in the code dependency tree they are.
* OSS Security, Quality and License policies must be woven into the development process. Knowing the number and type of open source licenses in your software can be important to the legal standing of your code and if it conflicts with any corporate standards. The licensing is also important in order to know the restrictions on changing the software.
* OSS Component Policy Examples
* Example Application Compositions Reports
* Example Use cases IDE, CI, repository, production applications
* Discussion

About Sonatype:

Sonatype operates the Central Repository, the industry's primary source for open-source components, housing more than 400,000 components and serving more than five billion requests per year from more than 60,000 organizations. The company has been a pioneer in component-based software development since its founding by Jason van Zyl, the creator of the Apache Maven build management system and the Central Repository.

'''March 2013'''

Topic: '''What is BSIMM?'''

Speaker: '''Nabil Hannan'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Nabil is Director of Vulnerability Assessments and Managing Consultant at Cigital.

The purpose of the BSIMM is to quantify the activities carried out by real software security initiatives. BSIMM is a study of the secure development practices of over 50 organizations, analyzed along the dimensions that were found in the data, not along preconceived ideas of what secure development should be.

BSIMM describes the work of 974 software security group members working with a satellite of 2039 people to secure the software developed by 218,286 developers.

The BSIMM describes 111 activities that any organization can put into practice. The activities are described in twelve practices grouped into four domains. Associated with each activity is an objective.

'''February 2013'''

Topic: '''BroBot'''

Speaker: '''Eric Kobrin, Akamai'''

When: Wednesday, February 6, 6:30 pm

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Eric Kobrin is a Senior Security Architect in the Infosec organization of Akamai Technologies, the global leader in Cloud-based application acceleration and content delivery. Eric has been involved in Software Architecture for over 15 years, having worked at such companies and IBM, Velocitude and eDiets.com. He has a passion for programming languages, security, and software performance and has worked in all layers of the software stack from hypervisors to complex servers and web applications. Eric's works have been published, presented at international conferences and patented.

His presentation will provide an analysis of the BroBot DDOS attacks, including discussion of:

* Vulnerable system discovery
* Zombie compromise
* Control structure
* Attack traffic
* Mitigation steps

'''January 2013'''

Topic: '''Third-Party Application Analysis: Best Practices and Lessons Learned'''

Speaker: '''Chad Holmes, Veracode'''

Location: [http://www.akamai.com/html/about/locations.html Akamai] at 8 Cambridge Center in Cambridge, MA

Chad Holmes will present details of the work Veracode has been doing with their 3rd Party program, discuss the technical and business challenges that have arisen during that time and lead a discussion on what team members can do to help drive adoption of security best practices across their vendor community.

The flow of the presentation is designed to drive discussion within an audience – both from a technical and business perspective with some anecdotal stories. Chad wants this to be an interactive discussion so he’ll have questions and you should bring yours I’ve already sent him some. The order of the presentation is:

· Adoption rates of externally developed software

· The risk within those apps

· Some deeper stats on what “3rd party” really means (total outsourcing/total COTS produced/open source/imported libraries/etc)

· Some raw data about our experiences (to show this is based on a large sample size rather than “Look how awesome Veracode is!”)

· Challenges that will be faced (business, intellectual property, policy, analysis capabilities, etc)

· Best Practices for high rates of adoption

· Lessons Learned and Recommendations

Chad Holmes has over 10 years of software development and application security experience. During his time at Veracode, Chad has lead the redesign and execution of the third-party analysis process to allow for a more streamlined approach while still addressing common ISV intellectual property concerns. In addition to his third-party analysis responsibilities, Chad's previous work as a Security Program Manager has lead to the successful roll out and improvement of multiple corporate application security groups.

'''June 2012'''
Location - Microsoft Waltham (201 Jones Rd., Sixth Floor Waltham, MA)

Speaker '''Will Vandevanter - Rapid 7'''

'''Fingerprinting web applications of all kinds'''

This turbo talk will introduce a new Metasploit module that fingerprints "known" web applications, attempts the default credentials for the application, and runs an associated exploit or authenticated access module if applicable. Some example fingerprints in the database target common enterprise web applications including Microsoft products (Outlook Web Access, Sharepoint), printers (Xerox Document Centre), security cameras, routers, and others.

Will Vandevanter is a senior penetration tester and researcher at Rapid7. His focus interests include web application security and secure code. He has previously spoken at Defcon, SOURCE, BSides LV, and other conferences.

'''May 31 2012'''

Location - Jobspring, Boston. 545 Boylston st.

Speaker - '''Glenn Gramling, Vice President, Cenzic'''

“Cloudy with a Chance of Hack”

Cloud computing is a cost effective and efficient way for enterprises to automate their processes. However organizations need to be aware of the pitfalls of the many cloud solutions out there - one of the main being security. Most cloud applications were built for ease of use and without security necessarily in mind. Companies need to be asking their solution providers about the security measures used in developing the application and get an independent verification to make sure there are no gaping holes. With over 75% of attacks occurring through the Web, any attack through these applications can lead to leakage of confidential information and embarrassment. In this session, we'll give attendees tips and tricks to prepare them for the potential of "stormy weather."

Glenn Gramling is responsible for global sales and business development for Cenzic’s application security.

'''April 11, 2012'''

Location - Microsoft Waltham (201 Jones Rd., Sixth Floor Waltham, MA)

Speaker - '''David Eoff, Senior Product Marketing Manager, HP Enterprise Security'''

David is a Senior Product Marketing Manager, within the Enterprise Security Products division of HP focused on Fortify application security. His 18+ years of background in software and hardware enterprise marketing provides a solid foundation for his marketing of the HP security solutions.

Prior to joining Fortify in 2009 and being acquired by HP, David ran Firewall and IPS marketing for the Security division of Nokia Corporation. In addition, he has held multiple positions in product marketing, product management, channel marketing and sales while working for Oracle, EMC, Legato, BMC Software and several start-ups.

Topic - '''Gray, the New Black: Gray-Box Vulnerability Testing'''

Over the years, two key techniques have emerged as the most effective for finding security vulnerabilities in software: Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST). While DAST and SAST each possess unique strengths, the “Holy Grail” of security testing is thought to be “hybrid” – a technique that combines and correlates the results from both testing methods, maximizing the advantages of each. Until recently, however, a critical element has been missing from first generation hybrid solutions: information about the inner workings and behavior of applications undergoing DAST and SAST analysis.

This presentation will introduce you to the next generation of hybrid security analysis – what it is, how it works, and the benefits it offers. It will also address (and dispel) the claims against hybrid, and leave you with a clear understanding of how the new generation of hybrid will enable organizations to resolve their most critical software security issues faster and more cost-effectively than any other available analysis technology.

'''March 8, 2012, with the Boston Security Meetup group'''

Location - [http://maps.google.com/maps?q=Jobspring+Partners,+Boylston+Street,+Boston,+MA&hl=en&sll=42.362243,-71.081628&sspn=0.019549,0.037594&oq=jobspring&t=v&hq=Jobspring+Partners,&hnear=Boylston+St,+Boston,+Massachusetts&z=17 JobSpring, Boylston St.]

Topic - '''Corporate Espionage for Dummies: The Hidden Threat of Embedded Web Servers'''

Speaker - VP for Security Research at ZScaler, along with other speakers at the security meetup.

Today, everything from kitchen appliances to television sets come with an IP address. Network connectivity for various hardware devices opens up exciting opportunities. Forgot to lower the thermostat before leaving the house? Simply access it online. Need to record a show? Start the DVR with a mobile app. While embedded web servers are now as common as digital displays in hardware devices, sadly, security is not. What if that same convenience exposed photocopied documents online or allowed outsiders to record your telephone conversations? A frightening thought indeed.

Software vendors have been forced to climb the security learning curve. As independent researchers uncovered embarrassing vulnerabilities, vendors had little choice but to plug the holes and revamp development lifecycles to bake security into products. Vendors of embedded web servers have faced minimal scrutiny and as such are at least a decade behind when it comes to security practices. Today, network connected devices are regularly deployed with virtually no security whatsoever.

The risk of insecure embedded web servers has been amplified by insecure networking practices. Every home and small business now runs a wireless network, but it was likely set up by someone with virtually no networking expertise. As such, many devices designed only for LAN access are now unintentionally Internet facing and wide open to attack from anyone, regardless of their location.

Leveraging the power of cloud based services, Zscaler spent several months scanning large portions of the Internet to understand the scope of this threat. Our findings will make any business owner think twice before purchasing a 'wifi enabled' device. We'll share the results of our findings, reveal specific vulnerabilities in a multitude of appliances and discuss how embedded web servers will represent a target rich environment for years to come.

'''December 13, 2011, 6:30, Microsoft NERD, Cambridge, Horace Mann Room'''

'''Jeremiah Grossman – Founder and CTO WhiteHat Security'''

Directions: http://microsoftcambridge.com/About/Directions/tabid/89/Default.aspx

'''September 14 2011'''

'''Dinis Cruz - OWASP O2 Platform'''

The O2 Platform is focused on automating application security knowledge and workflows. It is a library of scriptable objects specifically designed for developers and security consultants to be able to perform quick, effective and thorough source code-driven application security reviews (blackbox + whitebox).

'''September 7 2011'''

'''Adriel Desautels – Differences between Penetration Testing and Vulnerability Scanning'''

'''July 2011'''

'''Anurag Agarwal, the founder of MyAppSecurity'''

'''Session 1 - Managing Risk with Threat Modeling'''
Threat Modeling can help by guiding the Application Development Teams to ensure your Security Policies get properly coded into the Applications at time of Development. By creating pre-approved methods of coding for your development teams, and applying them in a repeatable and scalable process, you can assist your development teams in building a secure application easily and effortlessly.

'''Session 2 - False Positive, False Negative and False Sense of Security'''
This interactive session will talk about the pros and cons of using black box testing tools and discuss their effectiveness in building a mature software security program.

'''Thursday June 2'''

Location - '''Microsoft NERD''' - http://microsoftcambridge.com/About/Directions/tabid/89/Default.aspx

'''Topic - Bringing Sexy Back: Defensive Measures That Actually Work'''

Presenter - Paul Asadoorian, Founder & CEO, PaulDotCom Enterprises

There is a plethora of information available on how to break into systems, steal information, and compromise users. As a penetration tester, I have performed testing on a regular basis that reveals severe security weaknesses in several organizations, and many of my peers have reported on the same. However, once you "own" the network and report on how you accomplished your goals, now what? Sure, we make defensive recommendations, but consistently it has been proven that security can be bypassed. Not enough focus is given to what works defensively. We have a lot of technology at our disposal: firewalls, intrusion detection, log correlation, but it provides little protection from today's threats and is often not implemented effectively. This talk will focus on taking an offensive look at defense. Applying techniques that are simple, yet break the mold of traditional defensive measures. We will explore setting up "traps" for attackers, slowing them down with simple scripts, using honeypots, planting bugs, and most importantly tying these methods to "enterprise security". This talk will also include real-world examples of the techniques in action from a live, heavily attacked site. Topics will include:

*Using wireless “attacks” on the attackers
*Implementing the Metasploit Decloak engine to find the attackers
*Setting traps to detect web application attacks
*Integrating results into your enterprise log management tool

The goal of this talk is to make defense “sexy”…

'''Presenter Bio'''

Paul Asadoorian is currently the "Product Evangelist" for Tenable Network Security, where he showcases vulnerability scanning and management through blogs, podcasts and videos. Paul is also the founder of PaulDotCom, an organization centered around the award winning "PaulDotCom Security Weekly" podcast that brings listeners the latest in security news, vulnerabilities, research and interviews with the security industry's finest. Paul has a background in penetration testing, intrusion detection, and is the co-author of "WRT54G Ultimate Hacking", a book dedicated to hacking Linksys routers.

'''Thursday May 26'''

Location - Microsoft Waltham (201 Jones Rd., Sixth Floor Waltham, MA)

'''Topic - OWASP Top 10 issue #4 – Insecure Direct Object Reference'''

Presenter - Jim Weiler, Sr. Mgr. Information Security, Starwood Hotels and President of OWASP Boston

Jim Weiler will discuss threat models, risks and various remediations of issue #4 in the 2010 OWASP Top 10 – Insecure Direct Object References.

'''Topic - A Web-Application Architecture for Regulatory Compliant Cloud Computing'''

Presenter - Arshad Noor, StrongAuth

The emergence of cloud-computing as an alternative deployment strategy for IT systems presents many opportunities, yet challenges traditional notions of data-security. The fact that data-security regulations are developing teeth, leaves information technology professionals perplexed on how to take advantage of cloud-computing while proving compliance to regulations for protecting sensitive information.

This presentation presents an architecture for building the next generation of web-applications. This architecture allows you to leverage emerging technologies such as cloud-computing, cloud-storage and enterprise key-management (EKM) to derive benefits such as lower costs, faster time-to-market and immense scalability with smaller investments - while proving compliance to PCI-DSS, HIPAA/HITECH and similar data-security regulations.

'''Presenter Bio'''

Arshad Noor is the CTO of StrongAuth, Inc, a Silicon Vally-based company that specializes in enterprise key management. He is the designer and lead-developer of StrongKey, the industry's first open-source Symmetric Key Management System, and the KeyAppliance - the industry's first appliance combining encryption, tokenization, key-management and a cryptographic hardware module at an unprecedented value. He has written many papers and spoken at many forums on the subject of encryption and key-management over the years.

''' CANCELLED '''

'''Topic – Secure Application design and Coding''' -- CANCELLED

Presenter - Josh Abraham, Rapid 7

'''Speaker Bio '''

'''April 2011'''

Ed Adams Security Innovation -- the new OWASP Exams Project and the work being done by the OWASP Academies Working Group

<br>

'''March 2011'''

Josh Abraham, Rapid 7

Owning the world, one mobile app at a time, and web services pen testing.

<br>

'''Febrary 2011'''

Rob Cheyne, CEO of Safelight Security -

Security Leadership series: Delivering a successful security presentation

<br>

'''December 2010'''

Application Architecture Security Assessment - Second session

Rob Cheyne, CEO SafeLight Security Advisors

<br>

'''November 2010'''

Open SAMM – Software Assurance Maturity Model

Shakeel Tufail is the Federal Practice Manager at Fortify, an HP company.

<br>

'''October 2010'''

Rob Cheyne, CEO SafeLight Security Advisors Overview: In this highly interactive two-part workshop, Rob Cheyne of Safelight Security will show you the basics of conducting a real-world architecture & design review. This workshop draws from Safelight's Security Architecture Fundamentals training course, a two-day course frequently used to teach Fortune 500 companies how to look at their system architectures from both the hacker's and the designer’s point of view.

'''July 2010'''

Lightning Talk – Rob Cheyne, CEO Safelight Security Advisors In this installment of the Safelight lightning talks series, Rob will present the basics of a Cross-site Request Forgery (CSRF).

Main Presentation - Drive-by Pharming with MonkeyFist

Joey Peloquin - Director of Application Security, Fishnet Security

'''June 2010'''

Rob Cheyne Lightning Talk - topic to be announced

Main Presentation - Ryan Barnett The Web Hacking Incident Database (WHID) is a Web Application Security Consortium project dedicated to maintaining a list of web applications related security incidents. Ryan Barnett is director of application security research at Breach Security where he leads Breach Security Labs.

'''May 2010'''

Rob Cheyne Lightning Talk - SQL Injection

Vinnie Liu - Data Exposure, New Approaches to Open Source Intelligence Techniques, and Incident Handling

<br>

'''April 2010'''

Dan Hestad Security Innovation Dan will be talking about his experiences with PCI and web applications, and answering questions about do's and don'ts of acceptable PCI practices in web applications.

'''March 2010'''

Zack Lanier - Disclosure Samsara, or "the endless vulnerability disclosure debate"

http://n0where.org/talks/samsara_20100310.html

http://n0where.org/talks/samsara_20100310.pdf (very large PDF)

<br>

'''February 2010'''

Rob Cheyne of Safelight Security Advisors; New Technology, Same Old Vulnerabilities

<br>

'''January 2010 at Microsoft NERD, Cambridge'''

Josh Abraham, Rapid 7 Technologies

'''December 2009'''

Eric Bender, Cenzic

'''November 2009'''

Jim Weiler, Sr. Mgr. Information Security, Starwood Hotels - Web Application Vulnerability Scanners

Mush Hakhinian, Leader, Application Security Practice, IntraLinks - Secure coding with no money down using SONAR: unleashing the power of open-source code analysis tools

<br>

'''October 2009'''

Paul Schofield, Senior Security Engineer, Imperva - From Rivals to BFF: WAF & VA Unite

<br>

'''September 2009 at CORE Technologies, Boston'''

Paul Asadoorian, Pauldotcom.com

Alex Horan, CORE Security

<br>

'''May 2009'''

Joey Peloquin, Fishnet Security, Secure SDLC: The Good, the Bad and the Ugly [http://www.owasp.org/images/4/48/SecureSDLC-GoodBadUgly.pdf presentation pdf]

<br>

'''March 2009'''

Sabha Kazerooni, Security Compass - Exploit Me tools; Framework Level Threat Analysis

[http://www.owasp.org/images/5/5a/Security_Compass_Exploilt_Me.pdf ExploitMe Document]

[http://www.owasp.org/images/e/ef/Security_Compass_Framework-level_Threat_Analysis.pdf Framework Level Threat Analysis document]

Meeting Pizza Sponsor - Arcot

Arcot is a leader in online fraud prevention, strong authentication and eDocument security. Arcot's solutions are easily deployed, low-cost and extremely scalable, allowing organizations to transparently protect their users from fraud without changing user behavior or requiring expensive hardware.

Arcot can be contacted thru Michael Kreppein, michael.kreppein@arcot.com, 617-467-5200

'''December 2008'''

Brian Holyfield, Gothem Digital Science

Tamper Proofing Web Applications http://www.gdssecurity.com/l/b/2008/12/04/

'''June 2008'''

Jeremiah Grossman; Founder and CTO, Whitehat Security

Appetizer - Hacking Intranets from the Outside (Just when you thought your network was safe) Port scanning with JavaScript

Main Topic - Business Logic Flaws: How they put your Websites at Risk

'''March 2008'''

Chris Eng; Senior Director, Security Research, Veracode

Description – Attacking crypto in web applications

'''December 2007'''

Scott Matsumoto; Principal Consultant, Cigital

Description – You Say Tomayto and I Say Tomahto – Talking to Developers about Application Security

[https://www.owasp.org/images/5/5b/BostonOWASP200712-Cigital.pdf Cigital Presentation]

'''November 2007'''

Tom Mulvehill Ounce Labs

Description – Tom will share his knowledge and expertise on implementing security into the software development life cycle. This presentation will cover how to bring practicality into secure software development. Several integration models will be explored as well as solutions for potential obstacles

[https://www.owasp.org/images/f/f8/Ounce_OWASP_07NOV07ppt.zip Ounce presentation]

<br>

'''October 2007'''

George Johnson, Principal Software Engineer EMC; CISSP

An Introduction to Threat Modeling.

<br>

'''September 2007'''

Day of Worldwide OWASP 1 day conferences on the topic "Privacy in the 21st Century"

'''June 2007'''

Tool Talk - Jim Weiler - WebGoat and Crosssite Request Forgeries

Danny Allan; Director, Security Research, Watchfire

Topic: Exploitation of the OWASP Top 10: Attacks and Strategies

'''March 2007'''

Jeremiah Grossman, CTO Whitehat Security: Top 10 Web Application Hacks of 2006

<br>

'''January 2007'''

Dave Low, RSA the Security Division of EMC: encryption case studies

<br>

'''November 2006'''

<br>

'''September 2006'''

Mike Gavin, Forrester Research: Web Application Firewalls

<br>

'''June 2006'''

Imperva - Application and Database Vulnerabilities and Intrusion Prevention

Jim Weiler - Using Paros Proxy Server as a Web Application Vulnerability tool

<br>

'''May 2006'''

<br>

'''April 2006'''

Dennis Hurst; SPI Dynamics: A study of AJAX Hacking

Jim Weiler; OWASP Boston: Using Paros HTTP proxy, part 1. first meeting with all demos, no powerpoints!

<br>

'''March 2006'''

Mateo Meucci; OWASP Italy [http://www.owasp.org/images/8/8c/Anatomy_of_2_Web_App_Testing.zip Anatomy of 2 web attacks]

Tom Stracener; Cenzic Web Application Vulnerabilities

<br>

'''February 2006'''

Ron Ben Natan; Guardium CTO Database Security: Protecting Identity Information at the Source

<br>

'''January 2006'''

David Low, Senior Field Engineer: RSA Practical Encryption

<br>

'''December 2005'''

Paul Galwas, Product Manager: nCipher [http://www.owasp.org/docroot/owasp/misc/OWASP051207.ppt Enigma variations: Key Management controlled]

<br>

'''November 2005'''

Robert Hurlbut, Independent Consultant [http://www.owasp.org/docroot/owasp/misc/OWASP_Hurlbut_ThreatModelingforWebApplicaitons.zip Threat Modeling for web applications]

<br>

'''October 2005'''

Prateek Mishra, Ph.D. Director, Security Standards and Strategy: Oracle Corp Chaiman of the OASIS Security Services (SAML) Technical Committee - [http://www.owasp.org/docroot/owasp/misc/Federation-Introduction-Overview-01.ppt Identity Federation : Prospects and Challenges]

Ryan Shorter, Sr. System Engineer: Netcontinuum - Application Security Gateways

<br>

'''September 2005'''

Dr. Herbert Thompson, Chief Security Strategist: SecurityInnovation - How to Break Software Security

<br>

'''July 2005'''

Mark O'Neill, CTO: Vordel - [http://www.owasp.org/docroot/owasp/misc/MarkOneill.pdf Giving SOAP a REST? A look at the intersection of Web Application Security and Web Services Security]

'''June 2005'''

Arian Evans, National Practice Lead, Senior Security Engineer: Fishnet Security [http://www.owasp.org/conferences/appsec2005dc/schedule.html Overview of Application Security Tools]

<br>

'''May 2005'''

Patrick Hynds, CTO: Critical Sites - [http://www.owasp.org/docroot/owasp/misc/Passwords-Keys_to_the_Kingdom_Dev_V1.ppt Passwords - Keys to the Kingdom]

<br>

'''April 2005'''

Jonathan Levin - [http://www.owasp.org/docroot/owasp/misc/JLevinRandoms.pdf Of Random Numbers]

Jothy Rosenberg, Founder and CTO: Service Integrity - [http://www.owasp.org/docroot/owasp/misc/JothyRWebSvcsSec.ppt Web Services Security]

<br>

'''March 2005'''

Joe Stagner: Microsoft Let's talk about Application Security

<br>

'''Feb 2005'''

Application Security Inc. PowerPoint slides for the [http://www.owasp.org/docroot/owasp/misc/Anatomy+of+an+Attack.ppt Anatomy of a Database Attack.]

== Local Chapter Information ==

To find out more about the Boston chapter, just join the [http://lists.owasp.org/mailman/listinfo/owasp-boston OWASP Boston mailing list].

The chapter shipping/mailing address is:

OWASP Boston <br/>
35 Wachusett Dr <br/>
Lexington, MA 02421

== Links ==

[http://www.owasp.org/index.php/Reviews_of_security_podcasts Reviews of security podcasts]

[[2012 BASC Homepage|Boston Application Security Conference 2012]]

[[2011 BASC Homepage|Boston Application Security Conference 2011]]

[[2010 BASC Homepage|Boston Application Security Conference 2010]]

== Boston OWASP Chapter Leaders ==

'''President'''

- [mailto:jim.weiler@owasp.org Jim Weiler] 781 356 0067

'''Board of Directors'''

* Linda Leigh Aberdale
* Mark Arnold
* [mailto:tom.conner@owasp.org Tom Conner]
* Mike Perez
* [mailto:roy.wattanasin@owasp.org Roy Wattanasin]
* Pedro Marcano

<br>

__NOTOC__

[[Category:Boston]] [[Category:OWASP_Chapter]] [[Category:Massachusetts]]

3rd Party Javascript Management Cheat Sheet

2016-06-07T02:52:28Z

Jweiler: /* Server Direct Data Layer */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Third party vendor javascript ('''tags''') tags can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for third party vendor javascript, or ''''tags''''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a 'container' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. The marketing logic could have 30 or 40 different vendor tags on a single page. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
Changing third party vendors just means changing the data dissemination rules at the tag manager server, no changes are needed in the host code.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to connect to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html>

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-06-07T02:43:58Z

Jweiler: /* Server Direct Data Layer */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Third party vendor javascript ('''tags''') tags can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for third party vendor javascript, or ''''tags''''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a 'container' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code to send data layer data on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes. No interaction is needed with the third parties; they continue getting the data they expect but now it comes from different contexts that the host marketing technologists have chosen.
The data also goes directly only to the tag manager so the execution is fast. The event handler javascript does not have to send to multiple third party sites.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html>

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-06-07T02:32:17Z

Jweiler: /* Server Direct Data Layer */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Third party vendor javascript ('''tags''') tags can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for third party vendor javascript, or ''''tags''''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a 'container' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code on each page to send data layer data is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html>

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-06-07T02:30:34Z

Jweiler: /* Server Direct Data Layer */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Third party vendor javascript ('''tags''') tags can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for third party vendor javascript, or ''''tags''''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a 'container' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, a javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface. The event handler code is loaded from the tag manager servers on every page load.

'''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html>

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-06-07T02:23:43Z

Jweiler: /* Server Direct Data Layer */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Third party vendor javascript ('''tags''') tags can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for third party vendor javascript, or ''''tags''''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a 'container' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, the javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface.

'''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

This is also a very scaleable solution. Large ecommerce sites can easily have hundreds of thousands of URL and parameter combinations, with different sets of URLs and parameters being included in different marketing analysis campaigns. For example user actions in pages about specified cities, from specified locations on specified days should send data layer elements 1, 2 and 3. User actions in pages about other cities should send data layer elements 2 and 3 only. Since the event handler code on each page is controlled by the host developers or marketing technologists using the tag manager developer interface, the business logic about when and what data layer elements are sent to the tag manager server, can be changed and deployed in minutes.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html>

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-06-07T01:58:19Z

Jweiler: /* Server Direct Data Layer */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Third party vendor javascript ('''tags''') tags can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for third party vendor javascript, or ''''tags''''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a 'container' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, the javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface.

'''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; first to populate the data layer (generally on page load); then event handler javascript sends whatever data is needed from that page to the third party database or tag manager.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html>

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-06-07T01:54:03Z

Jweiler: /* Server Direct Data Layer */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Third party vendor javascript ('''tags''') tags can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for third party vendor javascript, or ''''tags''''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a 'container' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page. The data layer is created by the host developers.

When specific events happen that the business has defined, the javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it. The event handler code is created by the host developers using the tag manager developer user interface.

'''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; to populate the data layer then to send whatever data is needed from that page to the third party database or tag manager.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html>

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-06-07T01:52:45Z

Jweiler: /* Server Direct Data Layer */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Third party vendor javascript ('''tags''') tags can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for third party vendor javascript, or ''''tags''''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a 'container' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page.

When specific events happen that the business has defined, the javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it.

The data layer is created by the host developers. The event handler code is created by the host developers using the tag manager developer user interface.
'''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; to populate the data layer then to send whatever data is needed from that page to the third party database or tag manager.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html>

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-06-07T01:52:21Z

Jweiler: /* Server Direct Data Layer */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Third party vendor javascript ('''tags''') tags can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for third party vendor javascript, or ''''tags''''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a 'container' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page.

When specific events happen that the business has defined, the javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it.

The data layer is created by the host developers. The event handler code is created by the host developers using the tag manager developer user interface.
'''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; to populate the data layer then to send whatever data is needed from that page to the third party database or tag manager.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html>

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-06-07T01:51:06Z

Jweiler: /* Server Direct Data Layer */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Third party vendor javascript ('''tags''') tags can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for third party vendor javascript, or ''''tags''''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a 'container' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element or the description of a user action. The data layer is the complete set of values that all vendors need for that page.

The data layer can perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

When specific events happen that the business has defined, the javascript handler for that event sends values from the data layer directly to the tag manager server. The tag manager server then sends the data to whatever third party or parties is supposed to get it.

The data layer is created by the host developers. The event handler code is created by the host developers using the tag manager developer user interface.
'''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; to populate the data layer then to send whatever data is needed from that page to the third party database or tag manager.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html>

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-06-07T01:37:50Z

Jweiler: /* Server Direct Data Layer */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Third party vendor javascript ('''tags''') tags can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for third party vendor javascript, or ''''tags''''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a 'container' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

'''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; to populate the data layer then to send whatever data is needed from that page to the third party database or tag manager.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html>

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-06-07T01:37:15Z

Jweiler: /* Server Direct */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Third party vendor javascript ('''tags''') tags can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for third party vendor javascript, or ''''tags''''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a 'container' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct Data Layer ==

The tag manager developer user interface can be used to create javascript that can get data from anywhere in the browser DOM and store it anywhere on the page. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

'''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects. The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element. The data layer is the complete set of values that all vendors need for that page.

The data layer can also perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; to populate the data layer then to send whatever data is needed from that page to the third party database or tag manager.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html>

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-06-07T01:28:39Z

Jweiler: /* Server Direct Data Layer */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Third party vendor javascript ('''tags''') tags can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for third party vendor javascript, or ''''tags''''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a 'container' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct ==

The tag manager developer user interface can be used to get data from anywhere in the browser DOM. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

To create a data layer, the host site owner generate using the tag manager developer user interface will get and send data values to the tag manager or tag aggregator site which then sends the data to vendors. '''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects. The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element. The data layer is the complete set of values that all vendors need for that page.

The data layer can also perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; to populate the data layer then to send whatever data is needed from that page to the third party database or tag manager.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html>

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-06-07T01:26:28Z

Jweiler: /* Server Direct Data Layer */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Third party vendor javascript ('''tags''') tags can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for third party vendor javascript, or ''''tags''''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a 'container' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct ==

The tag manager developer user interface can be used to get data from anywhere in the browser DOM. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

To create a data layer, the host site owner generate using the tag manager developer user interface will get and send data values to the tag manager or tag aggregator site which then sends the data to vendors. '''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; to populate the data layer then to send whatever data is needed from that page to the third party database or tag manager.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html>

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-06-07T01:24:38Z

Jweiler: /* Server Direct */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Third party vendor javascript ('''tags''') tags can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for third party vendor javascript, or ''''tags''''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a 'container' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct ==

The tag manager developer user interface can be used to get data from anywhere in the browser DOM. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to make the generated code secure is to confine it to getting DOM data from a host defined data layer.

To create a data layer, the host site owner generate using the tag manager developer user interface will get and send data values to the tag manager or tag aggregator site which then sends the data to vendors. '''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects. The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element. The data layer is the complete set of values that all vendors need for that page.

The data layer can also perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; to populate the data layer then to send whatever data is needed from that page to the third party database or tag manager.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html>

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-06-07T01:21:43Z

Jweiler: /* Server Direct */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Third party vendor javascript ('''tags''') tags can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for third party vendor javascript, or ''''tags''''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a 'container' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct ==

The tag manager developer user interface can be used to get data from anywhere in the browser DOM. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to constrain the generated code is to confine it to getting DOM data from a host defined data layer.

To create a data layer, the host site owner generate using the tag manager developer user interface will get and send data values to the tag manager or tag aggregator site which then sends the data to vendors. '''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects. The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element. The data layer is the complete set of values that all vendors need for that page.

The data layer can also perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; to populate the data layer then to send whatever data is needed from that page to the third party database or tag manager.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html>

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-06-07T01:18:38Z

Jweiler: /* Server Direct Data Layer */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Third party vendor javascript ('''tags''') tags can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for third party vendor javascript, or ''''tags''''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a 'container' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct ==

The tag manager developer user interface can be used to get data from anywhere in the browser DOM. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to constrain the generated code is to confine it to getting DOM data from a host defined data layer.

With this mechanism, only the javascript you (the host site owner) generate using the tag manager developer user interface will get and send data values to the tag manager or tag aggregator site which then sends the data to vendors. '''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects. The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element. The data layer is the complete set of values that all vendors need for that page.

The data layer can also perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

User interface tags cannot be made secure using the data layer architecture because their function (or one of their functions) is to change the user interface on the client, not to send data about the user actions.

Analytics tags can be made secure using the data layer architecture because the only action needed is to send data from the data layer to the third party. Only first party code is executed; to populate the data layer then to send whatever data is needed from that page to the third party database or tag manager.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html>

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

3rd Party Javascript Management Cheat Sheet

2016-06-07T01:16:02Z

Jweiler: /* Introduction */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>
__TOC__{{TOC hidden}}
= Introduction =

Third party vendor javascript ('''tags''') tags can be divided into two types: user interface tags and analytic tags.

User interface tags have to execute on the client because they change the DOM; displaying a dialog or image or changing text etc.

Analytics tags send information back to a marketing information database; information like what user action was just taken, browser metadata, location information, page metadata etc.
The rationale for analytics tags is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.

The term '''host''' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript tag for marketing analysis of the user actions.

= Major risks =

The invocation of 3rd party JS code in a web application requires consideration for 3 risks in particular:
# The loss of control over changes to the client application,
# The execution of arbitrary code on client systems,
# The disclosure or leakage of sensitive information to 3rd parties.

== Risk 1: Loss of control over changes to the client application ==
This risk arises from the fact that there is usually no guaranty that the code hosted at the 3rd party will remain the same as seen from the developers and testers: new features may be pushed in the 3rd party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the 3rd party code (to prevent modifications while in-transit). See below for more details.

== Risk 2: Execution of arbitrary code on client systems ==
This risk arises from the fact that 3rd party JavaScript code is rarely reviewed by the invoking party prior to its integration into a website/application. As the client reaches the hosting website/application, this 3rd party code gets executed, thus granting the 3rd party the exact same privileges that were granted to the user (similar to [[Cross-site_Scripting_(XSS)|XSS attacks]]).

Any testing performed prior to entering production loses some of its validity, including *AST testing (IAST, RAST, SAST, DAST, etc.). While it is widely accepted that the probability of having rogue code intentionally injected by the 3rd party is low, there are still cases of malicious injections in 3rd party code after the organization's servers were compromised (Yahoo, January 2014). This risk should therefore still be evaluated, in particular when the 3rd party does not show any documentation that it is enforcing better security measures than the invoking organization itself, or at least equivalent. Another example is that the domain hosting the 3rd party JavaScript code expires because the company maintaining it is bankrupt or the developers have abandoned the project. A malicious actor can then re-register the domain and publish malicious code.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception), secure transmission of the 3rd party code (to prevent modifications while in-transit) and various types of sandboxing. See below for more details.

== Risk 3: Disclosure of sensitive information to 3rd parties ==
When a 3rd party script is invoked in a website/application, the browser directly contacts the 3rd party servers. By default, the request includes all regular HTTP headers. In addition to the originating IP address of the browser, the 3rd party also obtains other data such as the referrer (in non-https requests) and any cookies previously set by the 3rd party, for example when visiting another organization's website that also invokes the 3rd party script.

In many cases, this grants the 3rd party primary access to information on the organization's users / customers / clients. Additionally, if the 3rd party is sharing the script with other entities, it also collects secondary data from all the other entities, thus knowing who the organization's visitors are but also what other organizations they interact with.

A typical case is the current situation with major news/press sites that invoke 3rd party code (typically for ad engines, statistics and JavaScript APIs): any user visiting any of these websites also informs the 3rd parties of the visit. In many cases, the 3rd party also gets to know what news articles each individual user is clicking specifically (leakage occurs through the HTTP referrer field) and thus can establish deeper personality profiles.

Typical defenses include, but are not restricted to: in-house script mirroring (to prevent leakage of HTTP requests to 3rd parties). Users can reduce their profiling by random clicking links on leaking websites/applications (such as press/news websites) to reduce profiling. See below for more details.

= 3rd Party JavaScript Deployment Architectures =

There are three basic deployment mechanisms for third party vendor javascript, or ''''tags''''. These mechanisms can be combined with each other.

== Vendor Javascript on page ==

This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like [[Cross-site_Scripting_(XSS)|cross site scripting]] or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script type="text/javascript">/* 3rd party vendor javascript here */</script>
</body>
</html>

== Javascript Request to Vendor ==

This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript. Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Indirect request to Vendor through Tag Manager ==

This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.

The actual content that is returned from the aggregator or manager (i.e. the specific javascript files as well as exactly what they do) can be dynamically changed by host site employees using a graphical user interface for development, hosted on the tag manager site that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read, and when, to send to the vendor.

The tag manager developer user interface will generate code that does what the marketing functionality requires, basically determining what data to get from the browser DOM and when to get it. The tag manager always returns a 'container' javascript file to the browser which is basically a set of javascript functions that are used by the code generated by the user interface to implement the required functionality. Similar to java frameworks that provide functions and global data to the developer, the container javascript executes on the browser and lets the business user use the tag manager developer user interface to specify high level functionality without needing to know javascript.

=== Security Problems with requesting Tags ===

Previously described mechanisms are difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. The javascript is generally obfuscated so even seeing it is usually not useful. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript. This risk can be managed with the <i>Subresource Integrity</i> standard described below.

== Server Direct ==

The tag manager developer user interface can be used to get data from anywhere in the browser DOM. This can allow vulnerabilities because the interface can be used to generate code to get unvalidated data from the DOM (e.g. URL parameters) and store it in some page location that would execute javascript.

The best way to constrain the generated code is to confine it to getting DOM data from a host defined data layer.

With this mechanism, only the javascript you (the host site owner) generate using the tag manager developer user interface will get and send data values to the tag manager or tag aggregator site which then sends the data to vendors. '''This the most secure technique''' because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.

This requires cooperation between the host, the aggregator or tag manager and the vendors.

The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.

The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.

The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?

= Security Defense Considerations =

== Server Direct Data Layer ==

The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects. The data layer is either (1) a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants or (2) a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element. The data layer is the complete set of values that all vendors need for that page.

The data layer can also perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.

An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.

You the host page developer have to agree with the 3rd party vendors or the tag manager what attribute in the data layer will have what value so they can create the javascript to read that value.

== Indirect Requests ==

For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.

Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.

== Sandboxing Content ==

Both of these tools be used by sites to sandbox/clean DOM data.

* [https://github.com/cure53/DOMPurify DOMPurify] is a fast, tolerant XSS sanitizer for HTML, MathML and SVG. DOMPurify works with a secure default, but offers a lot of configurability and hooks.
* [https://github.com/hackvertor/MentalJS MentalJS] is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

== Subresource Integrity ==

[https://www.w3.org/TR/SRI/ Subresource Integrity] will ensure that only the code that has been reviewed is executed. The developer generates integrity metadata for the vendor javascript, and adds it to the script element like this:

<script src="https://analytics.vendor.com/v1.1/script.js"
integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC7CGiSNE64QUbHNPhzk8Xhm0djE6QqTpL0HzTUxk"
crossorigin="anonymous"></script>

It is important to know that in order for SRI to work, the vendor host needs [https://www.w3.org/TR/cors/ CORS] enabled. Also it is good idea to monitor vendor javascript for changes in regular way. Because somitime you can get '''secure''' but '''not working''' 3rd party code when vendor decides to update it.

== Keeping JavaScript libraries updated ==

[https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities OWASP Top 10 2013 A9] describes the problem of using components with known vulnerabilities. This includes JavaScript libraries. JavaScript libraries must be kept up to date, as previous version can have known vulnerabilities which can lead to the site typically being vulnerable to [[Cross-site_Scripting_(XSS)|Cross Site Scripting]]. There are several tools out there that can help identify such libraries. One such tool is the free open source tool [https://retirejs.github.io RetireJS]

== Sandboxing with iframe ==

You can also put vendor javascript into an iframe from different domain (e.g. static data host). It will work as a "jail"
and vendor javascript will not have direct access to the host page DOM and cookies. The host main page and sandbox iframe can communicate between each other via the [https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage postMessage mechanism].
Also, iframes can be secured with the iframe [http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ sandbox attribute]. For high risk applications, consider the use of [https://www.w3.org/TR/CSP2/ Content Security Policy (CSP)] in addition to iframe sandboxing. CSP makes hardening against XSS even stronger.

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<nowiki> </nowiki>
<iframe src="https://somehost-static.net/analytics.html" sandbox="allow-same-origin allow-scripts"></iframe>
</body>
</html>

<nowiki></nowiki>
<html>
<head></head>
<body>
...
<script>
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
if (event.origin !== "https://somehost.com:443") {
return;
} else {
// Make some DOM here and initialize other data required for 3rd party code
}
}
</script>
<nowiki> </nowiki>
<script src="https://analytics.vendor.com/v1.1/script.js"></script>
<nowiki> </nowiki>
</body>
</html>

== Vendor Agreements ==

You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.

= References =

https://randywestergren.com/widespread-xss-vulnerabilities-ad-network-code-affecting-top-tier-publishers-retailers/

= Authors and Primary Editors =

[[User:jweiler|Jim Weiler]] - Jim.Weiler@owasp.org<br/>

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]

User:Jweiler

2016-04-12T02:30:06Z

Jweiler: Created page with "I started programming in Fortran in 1970. I wrote a COBOL program as an undergraduate. I actually wrote a program in APL at UMASS Amherst in 1978 as a graduate student. I put..."