Your Secure DevOps Questions Answered


As SANS prepares for the 2nd Annual Secure DevOps Summit, Co-Chairs Frank Kim and Eric Johnson are tackling some of the common questions they get from security professionals who want to understand how to inject security into the DevOps pipeline, leverage leading DevOps practices, and secure DevOps technologies and cloud services.

If you are considering attending the Secure DevOps Summit or have already registered, this post is a good warmup, as these questions will be covered in-depth at the Summit on October 22nd-23rd in Denver, CO.

1. What do security professionals need to do to implement Secure DevOps processes?

SecDevOps requires security and compliance teams to integrate their processes, policies, and requirements into the same workflows being used by Development & Operations. This does not happen without the Security team understanding the current development and operations engineering process, technologies, and tools.

The Continuous Integration (CI) tool, is one of the most important pieces in the DevOps process, manages the workflow, executes steps, and integrates the entire toolchain together. Common examples include Jenkins, Visual Studio Team Services (VSTS), Travis, Bamboo, TeamCity.

Leveraging the CI tool, SecDevOps teams will start to integrate important security touch points such as:

  • Pre-Commit Security Hooks – Code checkers to scan for secrets (private keys, system passwords, cloud access keys, etc.) before committing code to version control.
  • Static Source Code Scanning – Scanning source code files (infrastructure templates, application source code) for security vulnerabilities in the build pipeline.
  • Security Unit Tests – Custom security unit tests written by the security and engineering teams to provide coverage for abuser stories and negative test cases.
  • Dynamic Application Security Testing – Scanning a running application for common security vulnerabilities (OWASP Top 10) and misconfigurations and enforcing acceptance criterial using tools such as Gauntlt / BDD Security.
  • Secrets Management – Automating the provisioning and storage of secrets using tools such as Vault, Conjure, AWS KMS, Azure Key Vault.
  • Continuous Monitoring – Monitoring the production environment for vulnerabilities, anomalies, and in progress attacks using tools such as statsd, graphite, graphana, etc.


2. What Secure DevOps tools should I use?

The authors of the SANS Institute’s DEV540 Secure DevOps & Cloud Application Security course put together a Secure DevOps Toolchain poster. Our SecDevOps Toolchain breaks the SecDevOps process down into 5 key phases with a detailed list of associated tools.

  • Pre-Commit: Security controls that can take place before code is checked into version control.
  • Commit: Fast, automated security checks that are invoked by continuous integration tools during the build.
  • Acceptance: Automated security acceptance tests, functional tests, and out of band security scans that are invoked by continuous integration tools as artifacts are delivered to testing / staging environments.
  • Production: Security smoke tests and configuration checks that are invoked by continuous integration tools as artifacts are delivered to the production environment.
  • Operations: Continuous security monitoring, testing, auditing, and compliance checks running in production and providing feedback to SecDevOps teams.


3. How important is culture in an organization moving towards SecDevOps?

John Wills, Damon Edwards, and Jez Humble came up with the CALMS to understand and describe DevOps:

  • Culture – People come first
  • Automation – Rely on tools for efficiency + repeatability
  • Lean – Apply Lean engineering practices to continuously improve
  • Measurement – Use data to drive decisions and improvements
  • Sharing – Share ideas, information and goals across organizational silos

There is a reason that Culture is first on the list. DevOps creates an open, diverse working environment that enables working together to solve problems, empower teams, fail fast, and continuously improve.

Here is the biggest challenge integrating the “Sec” into “DevOps”: traditional security cultures are always ready to say “no”, fail to share information across the organization, and do not tolerate failure.

This is also evidenced in how CISOs lead their organizations and interact with development teams and the rest of the business. There are three different types of CISOs: the dictator, the collaborator, and the partner.

By saying “no” the dictator doesn’t fully consider how security introduces unnecessary friction into existing development and business processes. For SecDevOps to be successful we need to move to be more of a collaborator by understanding engineering practices, process, and tools. Even better, security leaders can become partners by understanding business goals to earn a seat at the executive table.

4. How do you measure the success of SecDevOps?

SecDevOps teams often measure success by monitoring change frequency, deployment success / failure rates, and the mean time to recover (MTTR) from a failure.

For the “Sec” component, assume that a vulnerability assessment or penetration test uncovers a critical patch missing from a system. How long does it take the feedback from the security team to enter the operations workflow, build a new gold image, run automated acceptance tests to validate the changes, and roll the gold image into production? Mean time to recover (MTTR) is a critical metric for measuring success.

Measuring the # of vulnerabilities discovered via automated testing in the pipeline versus vulnerabilities escaping to production. This shows the effectiveness of the pipeline and improvements over time.

Tracking the window of exposure, or how long vulnerabilities remain open in production, provides important metrics for management to see progress.

These metrics also help handle managerial issues as you ask above because can show the process working and helping make the organization more secure.

5. What does “Security as code” mean?

A prerequisite for automation requires all steps to be written into code and checked into version control. Development engineering teams have been writing code since the beginning. Modern operations teams are now writing “infrastructure as code” using tools like Chef, Puppet, and Ansible to create and configure cloud infrastructure, on-premise infrastructure, gold images, and network devices.

Security as code takes this approach a step further by converting manual security and compliance steps into automated, repeatable scripts that can be executed inside a CI pipeline. Security tools are quickly evolving to have APIs and command line interfaces to support “security as code” instead of manually configuring a scanner and pressing a button.

In a SecDevOps world, security tools that cannot be automated through an API or from the command line are not worth purchasing.


Many security teams jump in too quickly and disrupt the engineering workflows. It is important to tackle one step at a time and start slowly. Security teams must ensure new security steps are working properly, evaluate results, fine tune scanners, and minimize false positives before even considering disrupting the workflow.

To learn more about DevOps and Cloud Security, check out DEV540: Secure DevOps and Cloud Application Security!

About the Authors
Eric Johnson is a co-founder and principal security engineer at Puma Security focusing on modern static analysis product development and DevSecOps automation. His experience includes application security automation, cloud security reviews, static source code analysis, web and mobile application penetration testing, secure development lifecycle consulting, and secure code review assessments.

Previously, Eric spent 5 years as a principal security consultant at an information security consulting firm helping companies deliver secure products to their customers, and another 10 years as an information security engineer at a large US financial institution performing source code audits.

As a Certified Instructor with the SANS Institute, Eric authors information security courses on DevSecOps, cloud security, secure coding, and defending mobile apps. He serves on the advisory board for the SANS Security Awareness Developer training program, delivers security training around the world, and presents security research at conferences including SANS, BlackHat, OWASP, BSides, JavaOne, UberConf, and ISSA.

Eric completed a bachelor’s degree in computer engineering and a masters degree in information assurance at Iowa State University, and currently holds the CISSP, GWAPT, GSSP-.NET, and GSSP-Java certifications.

Frank Kim is the founder of ThinkSec, a security consulting and CISO advisory firm. Previously, as CISO at the SANS Institute, Frank led the information risk function for the most trusted source of computer security training and certification in the world. With the SANS Institute, Frank continues to lead the management and software security curricula, helping to develop the next generation of security leaders.

Frank was also executive director of cybersecurity at Kaiser Permanente where he built an innovative security program to meet the unique needs of the nation’s largest not-for-profit health plan and integrated health care provider with annual revenue of $60 billion, 10 million members, and 175,000 employees.

Frank holds degrees from the University of California at Berkeley and is the author and instructor of popular courses on strategic planning, leadership, application security, and DevOps. For more, visit

Developer Security Awareness: How To Measure

In the previous post (What Topics To Cover), we laid the foundation for your developer security awareness-training program. Now let’s talk about the metrics we can collect to help improve our program.

It’s all about the metrics

As we previously mentioned, establishing a common baseline for the entire development team would be helpful. A comprehensive application security assessment should be performed before awareness training begins. For example, the SANS Software Security team has a free web based security assessment knowledge check: A knowledge check such as this allows you to create a baseline, establish core strengths and weaknesses, and steer the types of training to be provided.

As the awareness training takes place, knowledge checks are helpful at the end of each module along the way. These short quizzes ensure each student understands the topic that was presented and provides immediate feedback with any problem areas. The organization can use these metrics to track each team member’s progress and understanding along the way. Reports can be generated from this data to show how things are moving along, and even used for employee reviews.

The final step is to repeat the comprehensive security assessment again. This time use a similar exam with different questions covering the same topics. Ideally, the results will show improvement from the original baseline. Doing so will prove the effectiveness of our developer awareness program, and guarantee our funding as we onboard additional team members. Most importantly, the knowledge gained from the training program will help protect your organization with secure software moving forward.

We hope this series has helped form a vision for your developer security training. For more information, check out the SANS Securing The Human Developer program:

About The Author

Eric Johnson (@emjohn20) is a Senior Security Consultant at Cypress Data Defense and the Application Security Curriculum Product Manager at SANS. He is the lead author and instructor for DEV544 Secure Coding in .NET, as well as an instructor for DEV541 Secure Coding in Java/JEE. Eric serves on the advisory board for the SANS Securing the Human Developer awareness training program and is a contributing author for the developer security awareness modules. His experience includes web and mobile application penetration testing, secure code review, risk assessment, static source code analysis, security research, and developing security tools. He completed a bachelor of science in computer engineering and a master of science in information assurance at Iowa State University, and currently holds the CISSP, GWAPT, GSSP-.NET, and GSSP-Java certifications.

Developer Security Awareness: What Topics To Cover

In our last post (Is Security Your Top Priority), we discussed improving the security of our organizations with security awareness training for development teams. Now let’s talk about the security training we should provide.

What Topics To Cover

All team members have different knowledge levels of the various threats facing our applications. Some have received little or no application security training. Some may have taken a few courses in college that mentioned some common security issues. A few may have received in-depth application security training from a previous employer. The only way to guarantee everyone is on the same page is to establish a common baseline for all team members.

The first step is covering the fundamental aspects of application security. In this phase, introduce all team members to the attacker. Explaining who will be attacking their applications, along with their motivations, and introducing the attack methodology and the steps an attacker will take to compromise their applications will help them understand why security is important. By the end of this topic, everyone will understand the role they play in protecting the company’s assets.

Next, cover the secure software development lifecycle. This is where security is integrated into the daily tasks handled by the development team. Introduce the development team to secure design techniques. Show them how integrating and automating security during construction and deployment will help secure their applications.

When everyone has a fundamental understanding of application security, focus on the different types of applications each team is responsible for. Ensure groups responsible for web applications understand the OWASP Top 10. Anyone working on mobile applications must take mobile security training. Be aware of emerging technologies, such as Cloud and HTML5, and ensure they are being adequately covered.

Finally, narrow the scope even further. Introduce the development team to platform-specific secure coding training. If mobile applications are being written using iOS and Android, make sure the development team understands how to use the security features provided in those frameworks. Address the other development teams supporting web sites using other platforms, such as Cold Fusion or PHP, in a separate training effort. This phase is best received if the platforms being covered are relevant to the audience.

This is a lot to cover, but no one said application security is easy. Taking the time and effort to cover these topics is the first step towards building secure software! In our final section, we will take a look at the different types of metrics that we can collect, and how they can help steer our security program.

WhatWorks in Application Security Poster

We are excited to announce the new WhatWorks in Application Security Poster!

The front side of the poster focuses on why application security is important to any organization and the critical steps needed to make an application security program successful, including:

  • Design: Review security requirements, security architecture, secure coding standards, and the tools your team can use to create secure software design from the beginning
  • Test: Methods for testing your applications including dynamic analysis and static analysis tools, plus checklists for evaluating commercial tools and third-party penetration testing firms
  • Fix: Covers code remediation and identifies some products that can be used for virtual patching
  • Govern: Secure SDLC processes, metrics and reporting, and evaluating application security training

On the reverse side, the Securing Web Application Technologies (SWAT) checklist provides an easy-to-reference set of best practices that raise awareness and help development teams create more secure applications. Development teams can use the checklist to identify the minimum standard required to neutralize vulnerabilities their applications in the following areas:

  • Data Protection
  • Authentication
  • Access Control
  • Input & Output Handling
  • Session Management
  • Error Handling & Logging
  • Configuration & Operations

Please visit to have a physical copy of the poster mailed to you (US only) or download a copy of it now!

HTML5: Risky Business or Hidden Security Tool Chest?

I was lucky to be allowed to present about how to use HTML5 to improve security at the recent OWASP APPSEC USA Conference in New York City. OWASP now made a video of the talk available on YouTube for anybody interested.


AppSec at RSA 2012 Conference

I attended the RSA conference last week in San Francisco for the first time, and enjoyed the city. Excellent restaurants like Slanted Door, Canteen, Barbacco and especially Commonwealth, the Wharf, Chinatown, the almost perfect weather.

I was surprised at the scale of the conference, the impressive number of IT security professionals who came from everywhere, and the even more impressive number of technology vendors represented. The exhibition floor was overwhelming: huge booths with their own bars and free drinks, lovely booth bunnies in racing suits and blue wigs, race cars, a robot, a real sumo wrestler, lots of games and contests, even a “beat the freak” – a chance to put on gloves and beat on a salesman. Most of the technology was targeted to the enterprise of course, SIEM systems and enterprise ID management systems, and highly scalable next generation and next next generation firewalls, and lots of endpoint security solutions. And vulnerability scanning technology of every kind.

I spent most of the week following the AppSec track, with a few interesting side trips. Monday was a full-day AppSec 101 seminar put on by different specialists, mostly vendors. The session on Secure Design was the same dull motherhood from Saltzer and Schroeder: defence in depth, least privilege, minimize the attack surface, compartmentalization, blah blah – it’s no wonder that so few people pay attention to this, there’s nothing clear or actionable except for maybe the simplest and most important principle: Don’t Trust Data from Clients.

But there were a few cool takeways. I learned about FIRST.Org the Forum of Incident Response and Security Teams and their vulnerability scoring model for rating the risk of IT security vulnerabilities, which is useful. The session on security testing did a good job of covering dynamic and static analysis, fuzzing and manual testing, a pleasantly lucid explanation of how static analysis works, and when to use tools vs manual testing. One key point that kep coming up is that it’s not finding the vulnerabilities that is the hard work. It’s fixing them – deciding what to fix, making the case to fix them, dealing with the “blast radius” problem (many security fixes require changing different parts of the code) and making sure not to break the rest of the system.

Tuesday.  I skipped the keynotes on Tuesday and most of the keynotes on other days – with a couple of exceptions the keynotes were a waste of an impressive venue and the audience’s time – execs from security vendors playing with samurai swords and other silliness.

Jacob West from Fortify’s session on emerging security problems on mobile platforms was quite interesting. A lot of the presentation focused on Android. Android’s permissioning model is unclear enough that programmers can make simple mistakes that can easily be exploited, and its message-passing scheme (intents) is open to hijacking and other kinds of attacks. And of course there’s SQL injection again, this time against local database storage on Android. Sigh.

A high-powered panel on Agile Software Security was a disappointment, turning into more of a bitch session about irresponsible development practices, which as I’ve said before isn’t specific or intrinsic to Agile development. The arguments again are that there’s not enough time to do scans and reviews in short sprints. This is patently wrong, I know it, because we do it – if a team is disciplined, they can fit the work into sprints incrementally as part of delivering a working system.

Because one of the panelists was from a WAF vendor the other panelists said cautiously positive things about WAFs especially as a solution for large legacy apps that are too expensive and risky to change or fix. But in other sessions, WAFs were not taken seriously as a real answer to security problems.

Wednesday’s opening panel on implementing AppSec programs with senior managers from Adobe, Microsoft and JP Morgan Chase was excellent – real life advice from people who have actually done the work to put in successful software security programs. Especially cool that l I got to meet Jim Routh who is now heading up the software security program at JP Morgan Chase, and whose earlier work at DTCC helped me get our own software security program started 5 plus years ago.

Brad Arkin at Adobe, a frequent presenter at the conference, gave some good advice on preparing for and exploiting a crisis, including always having an unlimited budget scenario, because someday you might be asked for what you would do if money isn’t a constraint and you had better not waste this chance.

A tragically under-attended session on software security programs at midsize companies which lacked star power but the panelists all knew their stuff and provided good advice on how to accomplish a lot with limited budgets and resources.  All of them leverage outsourced on demand services such as White Hat and Veracode rather than trying to do everything in-house.

Met Frank Kim from SANS for a beer. Came up with ideas to save the world. Drank more beer. Forgot what we talked about.

Thursday. An early morning Peer-to-Peer session on Software Security on A Budget, hosted by John Dickson from Denim Group. It was fun to share experiences with other managers on what we were doing, what was worth doing, what maybe wasn’t worth doing but we’re still doing it anyways. Everybody is doing some kind of application scanning (dynamic or static), although nobody believes that it is  enough to ensure that the software is secure. Some of the things that were making a difference were training and frameworks.  Developer training is important, but you get the most value in training the people (strong developers and testers) who really care about good software and who have the chops to take care of the technical problems. Invest in making sure that libraries and platform code are secure and that developers use it.

F-Secure’s CTO on Cyber Terrorism. No real evidence of cyber terrorism yet, but social communities and blogs provide terrorists with a beautiful way to build their stories and recruit. The Internet can be a scary place.

Dan Cornell at Denim Group on vulnerability remediation costs. An interesting analysis based on a still small set of data from some remediation projects. No real surprises. Problems that are harder to find (like through manual pen testing) are often harder to fix than problems that are found by scanners, many of which are trivial. Others like SQL injection while still straightforward, take longer because you have to change the code carefully (to use prepared statements properly). The time to fix a security bug is only a small part of the total amount of work – most of the time goes to testing that the fix was done properly regression testing and rollout. I hope that they continue to build on this dataset, it would be helpful to learn what kinds of fixes are riskier to make, which ones cause the most regressions.

Friday started off with one of the most interesting sessions of the conference for me, a presentation “This is Getting Ridiculous” by Jeremiah Grossman about the insecure state of web apps. The scale of the challenge that we are facing in software security, especially web application security, is enormous. We need 10x or more people that deeply understand appsec to help fix the problems that we have today on the web. And of course we keep building more systems with new technology like HTML 5 and Node.js that we don’t understand well enough yet, so we won’t even know what the security problems will be for a couple of more years at least, meaning that we will have a whole lot more problems to deal with. He recommends that more companies (and government agencies) consider following Google and Facebook’s bug bounty programs and try to hack themselves secure. If white hat hackers were motivated and allowed to hack any site, think about what they could find.

Scott Morrison talked about how moving to more open, simpler APIs, especially RESTful service APIs for mobile apps, creates a new class of security problems. APIs tend to be finer grained which means the attack surface is much bigger, and because they are finer-grained and closer to-the-metal they are self-documenting to attackers, easier to exploit. Like any interface, the key is to get the basics right and to scrub all input and output or you will get hosed.

The final presentation of the week for me was by Ivan Ristic on SSL and Browsers: the Pillars of Broken Security. SSL is the single most important basic security protocol on the web and it is not being used correctly, or not at all. Very few sites use SSL because it used to be expensive and they still think it is. More than 2/3 of the sites that do use it don’t always use it consistently and properly, they mix HTTP and HTTPS traffic and don’t protect private data and session information. Even if they do use it properly, most don’t have it configured correctly. SSL Labs gives only 9 of the top web sites an A on using and configuring SSL correctly (that number seems insanely low, but that’s what I wrote down…). The problem is only getting worse because if you spin up a popular web server stack today on Amazon EC2 for example, most of the stacks are not configured correctly by default.  Qualsys has just released a free SSL best practices guide that explains how to configure and use SSL correctly. Hopefully thousands of people will download it and follow it and at least get this basic stuff done right. But that’s probably wishful thinking.

The conference reinforced what I already knew. There are a lot of problems out there to be solved. App Security like so much else in information technology is mostly about getting the fundamentals right. Don’t trust data from outside. Use SSL and use it properly. Find security bugs AND fix them. Build secure code and use it.

Spot the Vuln – Shape

I was scared I was going to have some weird shape to my head and I was pleased that I didn’t.
Edward Furlong

Spot the Vuln uses code snippets from open source applications to demonstrate vulnerabilities in real world web applications. Every Monday morning a vulnerable code snippet is posted. Take a look at the vulnerable code and try to identify where the security vulnerability is. Every Friday, a solution is posted so you can check your answers. Each exercise is designed to last between 5 and 10 minutes. Do it while you drink your morning coffee and you will be on your way to writing more secure applications.

[sourcecode language="php"]



if(is_readable('html.php')) include_once('html.php');
 else die('Could not find HTML library.');
if(is_readable('mycommon.php')) require('mycommon.php');
else die('Could not open configuration file.');

 if(is_readable('lang.php')) include_once('lang.php');
 else die('Could not find language library.');


$msg = '';
$srch = '';


 $srch = search_bot();
 $param =array(
 echo HTML_TASK_ADD($param);  


function search_bot(){
global $mres,$_POST;

if($_POST['S_COMPID'] == '')
if($_POST['S_IP'] == '')
return ''; 

if($_POST['S_COMPID'] > ''){
	$s_id = str_replace('*',"%",$_POST['S_COMPID']);
$q = 'SELECT * FROM `bots` WHERE `FCompID` like ("'.$s_id.'") limit '.$_POST['S_RESULTS'];
 $result = mysql_query($q,$mres);
 return  HTML_serch_res_tbl($result);  
if($_POST['S_IP'] > ''){
	$s_ip = str_replace('*',"%",$_POST['S_IP']);
 $q = 'SELECT * FROM `bots` WHERE `ip_addr` like ("'.$s_ip.'") limit '.$_POST['S_RESULTS'];
 $result = mysql_query($q,$mres);
  return  HTML_serch_res_tbl($result);  


function HTML_serch_res_tbl($result){
global $LNG;	
	 $nr = @mysql_num_rows($result);
  return "<font color=#990000>Message</font>:<em> No Entries found.</em>";
$ret = " <br><table width=\"543\" border=\"0\" cellpadding=\"1\" cellspacing=\"1\"> "
." <tr class=\"file2\"> "
." <td colspan=\"8\" class=\"bhead\"><div align=\"center\">Select Results</div></td> "
." </tr> "
." <tr class=\"file2\"> "
." <td width=\"21\" bgcolor=#FCFCFC>Add</td> "
." <td width=\"26\" nowrap=\"nowrap\" bgcolor=#FCFCFC>Land</td> "
." <td width=\"82\" bgcolor=#FCFCFC nowrap=\"nowrap\">IP</td> "
." <td width=\"93\" bgcolor=#FCFCFC nowrap=\"nowrap\">Rep. Count total </td> "
." <td width=\"56\" bgcolor=#FCFCFC nowrap=\"nowrap\">Last Report</td> "
." <td width=\"100\" bgcolor=#FCFCFC nowrap=\"nowrap\">First Report</td> "
." <td width=\"40\" bgcolor=#FCFCFC nowrap=\"nowrap\">Bot Ver.</td> "
." <td width=\"44\" bgcolor=#FCFCFC nowrap=\"nowrap\">CompID</td> "
." </tr> ";	

About the Authors:
Brett Hardin and Billy Rios run, a website dedicated to helping developers understand secure coding practices. You can find out more about the authors by visiting

Spot the Vuln – Third

Sullivan’s Law: When given the choice between two alternatives, always pick the third!
Patrick H. Sullivan

Spot the Vuln uses code snippets from open source applications to demonstrate vulnerabilities in real world web applications. Every Monday morning a vulnerable code snippet is posted. Take a look at the vulnerable code and try to identify where the security vulnerability is. Every Friday, a solution is posted so you can check your answers. Each exercise is designed to last between 5 and 10 minutes. Do it while you drink your morning coffee and you will be on your way to writing more secure applications.

insert( $ninja_annc_table_name, array( 'begindate' => $ninja_annc_begindate, 'enddate' => $ninja_annc_enddate, 'message' => $ninja_annc_message, 'active' => '0', 'location' => $ninja_annc_location ) );
$wpdb->update( $ninja_annc_table_name, array( 'begindate' => $ninja_annc_begindate, 'enddate' => $ninja_annc_enddate, 'message' => $ninja_annc_message, 'location' => $ninja_annc_location ), array( 'id' => $ninja_annc_id ));

echo "window.location = '".$admin_url."'";
} // END submit handling if()

//This if...else() statement handles the nuts and bolts of our html output.
//Eventually it will be replaced by a switch().
//Flow goes: Edit Announcement? -> New Announcement? -> Table.
//This part of our If...else statement creates the editing HTML
if($_REQUEST['action'] == 'edit') { //BEGIN edit handling if()

$ninja_annc_id = $_REQUEST['ninja_annc_id'];
$ninja_annc_row = $wpdb->get_row("SELECT * FROM $ninja_annc_table_name WHERE id = $ninja_annc_id", ARRAY_A);

$ninja_annc_id = $ninja_annc_row['id'];
$ninja_annc_location = $ninja_annc_row['location'];
$ninja_annc_message = stripslashes($ninja_annc_row['message']);
$ninja_annc_begin = $ninja_annc_row['begindate'];
$ninja_annc_end = $ninja_annc_row['enddate'];
$rightnow = current_time("timestamp");

if($ninja_annc_end != 0){
$ninja_annc_begindate = date("m/d/Y", $ninja_annc_begin);
$ninja_annc_begintimehr = date("g", $ninja_annc_begin);
$ninja_annc_begintimemin = date("i", $ninja_annc_begin);
$ninja_annc_begintimeampm = date("a", $ninja_annc_begin);

$ninja_annc_enddate = date("m/d/Y", $ninja_annc_end);
$ninja_annc_endtimehr = date("g", $ninja_annc_end);
$ninja_annc_endtimemin = date("i", $ninja_annc_end);
$ninja_annc_endtimeampm = date("a", $ninja_annc_end);

$ninja_annc_ignore = 1;
$ninja_annc_begindate = date("m/d/Y", $rightnow);
$ninja_annc_enddate = date("m/d/Y", $rightnow);

//$ninja_annc_begindate = $ninja_annc_begindate.' '.$ninja_annc_begintimehr.':'.$ninja_annc_begintimemin.$ninja_annc_begintimeampm;

//echo $ninja_annc_begindate;
wp_tiny_mce( false, // true makes the editor "teeny"
"theme_advanced_path" => false

Edit Announcement - ID:

<input type="hidden" name="ninja_annc_id" value="">
Ignore Dates: <input type="checkbox" name="ignoredates" id="ignoredates" value="checked" >
Begin Date: <input type="text" class="date" name="begindate" id="begindate" value="" >
<select name="begintimehr" id="begintimehr" class="time" >
$x = 1;
while($x <= 12){
echo "<option";
if($x $x";


About the Authors:
Brett Hardin and Billy Rios run, a website dedicated to helping developers understand secure coding practices. You can find out more about the authors by visiting

Firefox 4 Security Features

Like no other release before it, Firefox 4 includes a number of significant security features. These features are addressing attacks that are in particularly hard to avoid by developers and in which the browser is more so the victim then the server.

These attacks, Cross Site Scripting (XSS), redirects to HTTP pages from HTTPS and Clickjacking use vulnerable web applications more as a mirror to bounce attacks into the browser. The browser can provide meaningful protection against these attacks, unlike for more server centric attacks like sql injection, for which the attacker is in full control of the client.

XSS and Content Security Policy (CSP)

We have seen a couple of prior attempts to assist browsers to detect XSS attacks. All of these attempts, (the NoScript plugin or the IE 8 “X-XSS-Protection:” header had the same problem: They had no idea what kind of script to expect on a particular page. In some cases, they could prevent reflected XSS just by comparing strings sent by the browser to strings being returned by the server. Neither NoSpring nor IE 8 did a sufficient job in preventing XSS and many users or web developers turned it off due to high false positive rates.

CSP takes a different approach: It uses server headers to tell the browser what kind of content to expect. That way, the browser can make a more intelligent decision as to how to block content that does not match the policy communicated by the server. I will probably discuss this feature in more detail in the future, but if you are interested, last months Monthly Threat Update webcast covered the main points. [1]

One CSP feature I would like to point out: The server may communicate as part of its policy a “Report-URI” which the browser can use to report any violations of the CSP. This is not only great to detect attacks, but even more so to detect legitimate features on your site that are not sufficiently covered by your policy.

If you would like to experiment: Just add “?csp=Y” to any URL. It will enable our test CSP. Right now, it is not very restrictive as I am still refining some of our content. We do also have a little CSP test page at which highlights some of the features.


Another neat feature to tell the browser more about how to connect to a given site. If the “Strict-Transport-Security” header is set, the browser will refuse any attempt to connect to the site via HTTP. The threat model here is that an attacker will inject a redirect to the HTTP version of the site while the user is browser a non HTTPS site (any site, not just the target). This could lead to the disclosure of confidential information like authentication cookies. Sure. This attack can be mitigated in part by setting the “secure” option of your session cookie. But it may not be so easy if the injection of the redirect happens during the login process.

This header has two parameters: A “max-age” indicating for how long this rule should be obeyed and a “includeSubdomain” parameter that will extend the rule to all subdomains. This header should be used on all HTTPS only sites.

Other changes

A few other changes:

– X-FRAME-OPTIONS Header: it can be used to prevent a site from being included in a frame. This option exists in other browsers as well (IE, Safari, Chrome). Some of the recent 3.6 versions of Firefox already included it and NoScript implemented it. CSP implements a more fine grained restriction on framing.
– User-Agent Header: Firefox 4 uses a less verbose user agent header which makes it a bit harder to track users

– Do-Not-Track Features: More about this later. It does signal sites if you don’t want to be tracked.