[SC-L] OWASP AsiaPac 2012 - Sydney, Australia: CFP and call for trainers
Colleagues, In 2012, OWASP is holding Global AppSec AsiaPac Conference in Sydney Australia! OWASP Asia Pacific is the foremost Application Security conference for the region, and brings together the community in a central meeting for 4 days to discuss and present on recent and current Application Security related topics. In previous years the conference has been held on the Gold Coast Australia, in 2012 the event has been moved to Sydney, and will be held at the Four Points Sheraton Darling Harbour from the 11th to the 14th of April 2012! The OWASP AppSec AsiaPac 2012 Call for Papers (CFP) is now open. Please visit the following URL to submit your abstract for the April 13-14, 2012 talks in Sydney Australia: http://sl.owasp.org/apac2012talks We will make the first round of selections, based on the CFPs we have received by February 17, 2012. The final closing date for submissions is Friday, March 3, 2012. We look forward to talk submissions over the coming weeks from security practitioners, researchers, thought leaders, and developers in the following content areas: * Research in Application Security Defense (Defense Countermeasures) * Research in Application Security Offense (Vulnerabilities Exploits) * Web Application Security * Critical Infrastructure Security * Mobile Security * Government Initiatives Government Case Studies * Effective case studies in Policy, Governance, Architecture or Life Cycle * OWASP Projects (turbo talks) Speakers will receive free admission (non-transferable) to the conference in return for delivering a 50 minute talk or for delivering a 25 minute OWASP Projects turbo talk. Call for Trainers OWASP AppSec AsiaPac 2012 is also currently soliciting training providers for the conference. Please visit the following URL to submit your training proposal for the April 11-12, 2012 training days in Sydney Australia: http://sl.owasp.org/apac2012training The following conditions apply for people or organizations that want to provide training at the conference: * Training provider should provide class syllabus / training materials. * Proceeds will be split 75/25 (OWASP/Trainer) for the training class. * OWASP will provide the Venue, Marketing with Conference materials, Registration and basic AV * Trainers will cover travel and accommodations for the instructor(s) and all course materials for students * OWASP will reserve up to 2 training slots at no cost and the trainer may reserve up to one slot at no cost * Price per attendee: 2-Day Class $995/ 1-Day Class $595 * Trainers can brand training materials to increase their exposure * Classes are to be focused around Application Security but are in no way limited to web application security. We will make the first round of selections, based on the Training proposals we have received by February 17, 2012. The final closing date for submissions is Friday, March 3, 2012. Please submit proposals to http://sl.owasp.org/apac2012training. All trainers will be required to submit a Training Instructor Agreement (https://www.owasp.org/images/8/80/APAC2012_Training_Instructor_Agreement.pdf ) in order to have their classed scheduled. Additional information can be found at http://www.appsecAPAC.org. Please forward to all interested practitioners and colleagues. If you wish to get involved, present or just find out more information about the conference, please contact the conference chair, Justin Derry, at jde...@owasp.org or the conference planning team at appsecasia2...@owasp.org. Regards, The AppSec AsiaPac 2012 Program Committee ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] Language agnostic secure coding guidelines/standards?
The OWASP materials are fairly language neutral. The closest document to your current requirements is the Developer Guide. I am also developing a coding standard for Owasp with a likely deliverable date next year. I am looking for volunteers to help with it, so if you want a document that exactly meets your needs ... Please join us! Thanks, Andrew On Nov 12, 2008, at 19:21, Pete Werner [EMAIL PROTECTED] wrote: Hi all I've been tasked with developing a secure coding standard for my employer. This will be a policy tool used to get developers to fix issues in their code after an audit, and also hopefully be of use to developers as they work to ensure they are compliant. The kicker is it needs to cover things ranging from cobol running on a mainframe, in house network monitoring software in c and perl through to web and desktop applications in java or .net. I've been doing some searching to see if there is anything similar online, but everything i've found is mostly focussed on web applications or language/platform specific. Does anyone know of something that may be what I'm looking for? It's basically going to be a checklist where every item will be something that can be audited, and the things that aren't relevant to a given application can be ignored. The broad sections I have so far are: Input/Output handling Session Control and Management Memory allocation and Management Authentication Management Authorisation Management Data Protection Logging and Auditing Application Errors and Exceptions Thanks in advance Pete ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com ) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] quick question - SXSW
Hi all, I have been specifically targeting developer conferences these last twelve months. I've had rejections from the likes of OSCON, and in fact, I was rejected from BlackHat, too. I have worked out the pattern to these conferences. You gotta SEX IT UP. Instead of submitting talks like Safe Ajax Coding Techniques or Securely using mainframe transactions in your web app, submit talks that are titled: How we pillage your app, identity rape your users, steal all your money, and retire in the Caribbean with the loot Then when you get there, start with a demo or three to end all demos. Totally scare them witless. Followed by a picture of a girly drink with an umbrella in it with a beach in the background, and take the girly drink to the talk, too. Once you've put the fear of god (or at least malicious attackers) into them, then you can: * Do the talk you had in mind all along (Securely using mainframe ...), and they'll learn what they needed to learn by attending your talk. This is not to say you should be a boring presenter, but we shouldn't shy away from saying to developers that they MUST do this stuff, or they'll be pwned. Just before the folks fill in their presenter feedback forms, do an ASTONISHING demo. Something they will remember when they're filling in the feedback. When you're at the top of the feedback pile, you'll get invited back. The program committees for these trendy conferences - with some very notable exceptions - are for the most part just as hostile / apathetic / know little about security as the attendees. Sometimes worse - many are truly hostile to security as it gets in the way of their fast and crappy beats correct every time mindset. So make your submission interesting to the program committee, so much so that they want to come see it, too. Once they start accepting the talks, sooner or later, after 10 years or so, we'll be able to submit the useful talks without any such cover. See the design pattern folks for proof. Arian - ARGH! Tell Anurag to check out ESAPI - it has already hard core white list encoding, direct object reference maps, easy user object manipulation (logout that actually does the right thing with one call, etc), safe system(), encrypted property files, integrity protection and encryption for hidden fields and cookies, and so on and on and on. Encoder:: canonicalize() Simplifies percent-encoded and entity-encoded characters to their simplest form so that they can be properly validated. decodeFromBase64() Decode data encoded with BASE-64 encoding. decodeFromURL() Decode from URL. encodeForBase64()Encode for base64. encodeForDN()Encode data for use in an LDAP distinguished name. encodeForHTML() Encode data for use in HTML content. encodeForHTMLAttribute() Encode data for use in HTML attributes. encodeForJavascript()Encode for javascript. encodeForLDAP() Encode data for use in LDAP queries. encodeForSQL() This method is not recommended. encodeForURL() Encode for use in a URL. encodeForVBScript() Encode data for use in visual basic script. encodeForXML() Encode data for use in an XML element. encodeForXMLAttribute() Encode data for use in an XML attribute. encodeForXPath() This implementation encodes almost everything and may overencode. normalize() Normalizes special characters down to ASCII using the Normalizer built into Java. It's already done! However, there's more to do - let's work together on those gaps (client AJAX ESAPI) instead of re-inventing the wheel. thanks, Andrew On Mar 13, 2008, at 4:11 AM, Arian J. Evans wrote: and Anurag will be releasing some APIs for java developers to actually do things like output encoding, where Java/J2EE is about 4 years behind the rest of the world. thanks, Andrew van der Stock Lead Author, OWASP Guide and OWASP Top 10 ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Silver Bullet turns 2: Mary Ann Davidson
Gary, Good interview. The discussion on being unable to develop trust relationships with contractors who release exploits was interesting, and I wished that there was more discussion on that point. I would have thought signing a contract made it easier to sue for breach of contract than untested laws (or bad laws like the UK's RIPA), so much so you'd really think twice as well as the negative downside of being considered untrustworthy with confidential data - which is like a plague to any consultancy business. I really wish Ms Davidson had gone into detail on their SDL, as to what is really in there, and where we could read it and review it. Oracle's is an interesting turn around considering back in 2005 / 2006, the research community and Oracle's relationship was at an all time low, essentially begging Oracle to put in an SDL and address the security defects properly without outside folks finding them first. I have since read that fences have been somewhat mended between researchers, such as David Litchfield, and Oracle. I still wince at that episode - it was entirely unprofessional of Oracle to attack Litchfield, who was practicing responsible disclosure for up to 600-800 days, when 30 is the norm. I personally was extremely unimpressed with Oracle's approach of shooting the messenger rather than fixing the product. I must admit that episode led me to dismiss Oracle as the walking dead as they obviously couldn't be trusted with data of value, and so didn't follow news about Oracle ... until this interview. I'm glad they're now using automated SCA tools and fuzzers, they're now finding most of the security issues themselves, have an internal review team, and my personal favorite - developer awareness / education. This is a 180 degree turnaround from the prior to 2005/2006 era. I particularly like that she's going to the universities and ask them to teach coding security. This is what they SHOULD have been doing rather than attacking the research community. I'm glad that Oracle is now drinking the kool aid and treating security as a fundamental software engineering requirement. It's about time. thanks, Andrew van der Stock Lead Author, OWASP Guide to Writing Secure Applications and OWASP Top 10 ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] COBOL Exploits
I've been researching web app - mainframe security from a software engineering perspective for about the last six months. If anyone from a mainframe background wants to collaborate, I'd be more than happy to share as I have a few challenges: a) I'm working from secondary resources (web pages, manuals, PDFs) b) I don't have access to a z/OS or similar system and thus cannot mock up a test environment to prove or disprove my hypotheses on how best to prevent certain classes of attack c) I really don't have a lot of experience with z/OS, COBOL, DB2, IMS, or CICS. Therefore, I could be missing some great resources and features. Saying that, I have made a bit of headway by applying first principles and trying to discover what is available to assist and protect against certain threats and attacks. I've just posted a draft entry to my blog detailing the first (and I mean first) post I've had brewing since May this year. It's nowhere near as good as I would have liked. I don't do exploits. You will not be seeing any how to hax0rs b1g ir0n from me. I don't see the relevance of arming script kiddies. Only the architects and developers need to know how to develop and maintain safer designs and code, and folks like me need to know what to look for to make sure it's in place. That said, from my personal research, this area is a total greenfield. The folks who know mainframe security simply don't come out of their shells often enough. They have the goods, but the goods are not really well known amongst the architects and devs I've dealt with. Most of the business folks who ask for their shiny new dodgy code to talk to old dodgy transactions don't see this risk and refuse to pay to have qualified folks review and remediate the security of the mainframe side. They see it as this reliable old workhorse - which is not broke, so don't fix it. And in my personal experience, they NEVER fix it. On another note, I'm really happy to see Fortify tackle the mainframe with their SCA products. It's really late and delayed, but better late than never. I know a bunch of sites that could use that tool if it works even 1% as well as the marketing is likely to make out. thanks, Andrew van der Stock Executive Director, OWASP Project Lead Author, OWASP Guide On Nov 2, 2007, at 1:45 PM, Peter G. Neumann wrote: Searching through http://www.csl.sri.com/neumann/illustrative.html gives these COBOL-related RISKS items. The initial character descriptors are defined there. In the citations, * R relates to RISKS (archives at risks.org) * S relates to SIGSOFT Software Engineering Notes (archives at www.sigsoft.org/SEN/ although more recent items also in RISKS) Vf West Drayton ATC system bug found in 2-yr-old COBOL code (S 16 3, R 11 30) \$fe IRS COBOL reprogramming delays; interest paid on over 1,150,000 refunds (S 10 3:12) S[H?] Election frauds, lawsuits, spaghetti code, same memory locations used for multiple races simultaneously, undocumented GOTOs, COBOL ALTER verb allowing self-modifying code, calls to undocumented/unknown subroutines, bypassable audit trails (S 11 3); Report from the Computerized Voting Symposium, August 1986 (S 11 5) Sie Data transfer Excel-COBOL loses voter data in 2003 Greenville Mississippi election (R 22 95) \$hi Man gets \$218 trillion phone bill (R 24 24); COBOL program? (R 24 27,29,30,33) f Discussion of date and century roll-over problems: Fujitsu SRS-1050 ISDN display phones fail on two-digit month (10); 1401 one-character year field; COBOL improvements; IBM 360 (S 20 2:13) [See Fred Ballard and Walt Murray (R 16 70 ff).] [Lots of stuff is relevant on COBOL's two-character year field and the entire Y2K saga.] ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com ) as a free, non-commercial service to the software security community. ___ Andrew van der Stock Executive Director, OWASP Lead Author, OWASP Guide smime.p7s Description: S/MIME cryptographic signature ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Mainframe Security
In my experience of reviewing COBOL and mainframes in general, it's worthwhile to evaluate doing bad things to the business logic. The designers are literal in their translation of the business requirements to specifications, and never think of the mis-use cases. Mainframe coders aren't paid to design and implementing missing links in the design, and are often penalized if they stray too far from the specification. Therefore, as Peter pointed out in a previous thread, almost all of the exploits for mainframes goes after the golden apples - the business logic and the underlying asset. Luckily, up until recently, data which violated the requirements wasn't easy to get in, but now it's more than easy: a) a system I am aware of used to be green screen only and had validation to prevent unauthorized characters like commas in the presentation layer. Once the underlying transaction was made available to process transactions from the Internet, customers finally could manipulate this data. Someone didn't bother to eliminate , as a valid character as it wasn't in the spec - they only had a few characters to eliminate and , wasn't one of them. The comma upset the strip (batch data) file. Caused several abends and a lot of sleepless nights for the folks whilst they worked out how to get rid of this troublesome character from a multi-gigabyte file and successfully re-run the batch without re-processing already processed transactions. b) I have spaces in my name. Galileo, the online booking system used by pretty much everyone is written on top of TPS, an old (and I mean OLD - it's older than me) OS for IBM mainframes. TPS is written in assembly language, as is most of the Galileo transactions for freight and self-loading freight (humans). If you try like me to enter the legally required spaces in your name as often as you can, it's nearly funny the number of times I've had to get manual assistance to get on planes and through the TSA checkpoint. I'm sure it's because Galileo doesn't handle spaces properly. I wonder what other characters it doesn't like. c) The EOF marker in EBCDIC works real well. If your outside program can send it in a field and it doesn't mean anything to anyone ... until it hits a file, you can cause a lot of problems, particularly with batch driven systems. Luckily, most front end systems I come across don't know what to do with low ASCII entries and either don't pass it on, or fail to translate it properly, thus preventing a workable attack. thanks, Andrew smime.p7s Description: S/MIME cryptographic signature ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] How is secure coding sold within enterprises?
In terms of creating a SDLC, pop out to Borders and get Howard and Lipner¹s ³The Security Development Lifecycle² ISBN 9780735622142 http://www.microsoft.com/mspress/books/8753.aspx It is simply the best text I¹ve read in a long time. You may be interested in the work Mark Curphey et al is doing at his new start up. They launched an ISM portal a couple of weeks back. http://www.ism-community.org/ If you¹re just after ideas on how to engage vendors, check out Curphey¹s blog for some nice insider posts: http://securitybuddha.com/2007/03/07/top-10-tips-for-hiring-web-application- pen-testers/ http://securitybuddha.com/2007/03/07/top-ten-tips-for-hiring-security-code-r eviewers/ http://securitybuddha.com/2007/03/08/top-ten-tips-for-managing-technical-sec urity-folks/ He ran Foundstone¹s services for a while, and built up a pretty good consultancy. The sort of metrics you¹re after are notoriously hard to find out in the wild. There¹s some folks capturing screenshots of enterprise dashboards. This may or may not help at all. http://dashboardspy.com/ Thanks, Andrew On 3/19/07 4:12 PM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: I agree with your assessment of how things are sold at a high-level but still struggling in that it takes more than just graphicalizing of your points to sell, hence I am still attempting to figure out a way to get my hands on some PPT that are used internal to enterprises prior to consulting engagements and I think a better answer will emerge. PPT may provide a sense of budget, timelines, roles and responsibilities, who needed to buy-in, industry metrics, quotes from noted industry analysts, etc that will help shortcut my own work so I can start moving towards the more important stuff. -Original Message- From: Andrew van der Stock [mailto:[EMAIL PROTECTED] Sent: Monday, March 19, 2007 2:50 PM To: McGovern, James F (HTSC, IT) Cc: SC-L Subject: Re: [SC-L] How is secure coding sold within enterprises? There are two major methods: 1. Opportunity cost / competitive advantage (the Microsoft model) 2. Recovery cost reductions (the model used by most financial institutions) Generally, opportunity cost is where an organization can further its goals by a secure business foundation. This requires the CIO/CSO to be able to sell the business on this model, which is hard when it is clear that many businesses have been founded on insecure foundations and do quite well nonetheless. Companies that choose to be secure have a competitive advantage, an advantage that will increase over time and will win conquest customers. For example (and this is my humble opinion), Oracle¹s security is a long standing unbreakable joke, and in the meantime MS ploughed billions into fixing their tattered reputation by making it a competitive advantage, and thus making their market dominance nearly complete. Oracle is now paying for their CSO¹s mistake in not understanding this model earlier. Forward looking financial institutions are now using this model, such as my old bank¹s (with its SMS transaction authentication feature) winning many new customers by not only promoting themselves as secure, but doing the right thing and investing in essentially eliminating Internet Banking fraud. It saves them money, and it works well for customers. This is the best model, but the hardest to sell. The second model is used by most financial institutions. They are mature risk managers and understand that a certain level of risk must be taken in return for doing business. By choosing to invest some of the potential or known losses in reducing the potential for massive losses, they can reduce the overall risk present in the corporate risk register, which plays well to shareholders. For example, if you invest $1m in securing a cheque clearance process worth (say) $10b annually to the business, and that reduces check fraud by $5m per year and eliminates $2m of unnecessary overhead every year, security is an easy sell with obvious targets to improve profitability. A well managed operational risk group will easily identify the riskiest aspects of a mature company¹s activities, and it¹s easy to justify improvements in those areas. The FUD model (used by many vendors - ³do this or the SOX boogeyman will get you²) does not work. The do nothing model (used by nearly everyone who doesn¹t fall into the first two categories) works for a time, but can spectacularly end a business. Card Systems anyone? Unknown risk is too risky a proposition, and is plain director negligence in my view. Thanks, Andrew On 3/19/07 11:35 AM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: I am attempting to figure out how other Fortune enterprises have went about selling the need for secure coding practices and can't seem to find the answer I seek. Essentially, I have discovered that one of a few scenarios
Re: [SC-L] Bumper sticker definition of secure software
NB: I am not speaking on behalf of my employer and this is my personal opinion. Banks in general do not use smart cards as they suffer from the same issue as two factor non-transaction signing fobs - they are somewhat trivial to trick users into giving up a credential. Connected keys are the worst - they induce laziness in the user and infer security which is not actually there. Smart card integration over web apps is non-existent. The HTTP 1.1 protocol does not support two factor transaction signing nor smart cards in general (unless you are just using SSL with a client-side cert, which is just as vulnerable as a normal IB app today if the attacker chooses a CSRF attack). Therefore, you need *something* extra to make 2FA USB fob authentication work. RSA has an ActiveX plugin (Keon WebPassport) which works great in an Intranet environment and you control all the resources. However, such solutions have a support overhead and locks users into just Win32 platform, and locks out pretty much any site that blocks ActiveX controls on their PCs. Here's why such devices will not fly: *) costs money to ensure that the crypto is compliant with national and international standards *) costs money to develop and deploy secure internal PKI and secure operational procedures to issue certificates for the devices. For the average institution, this is a lot of overhead. *) costs money to deploy (need to send out software, instructions, device, smart card) *) costs money to register users securely (is sending through the mail acceptable?) - this step was stuffed up in the UK's Chip and Pin roll out, so we have an excellent data point already http://www.theregister.co.uk/2004/09/16/chip_pin_crime_wave/ *) costs money to train users to only insert their smart card when your app is running and not just leave it in *) costs money to support users when your software gets the blame for their user's support woes (whether true or not) *) doesn't improve security if the user can just say yes. The typical dialog for these things is Please press Submit to pay Nice Person $100 using your token. If the app suffers from an XSS, why is this prompt safe? Can you trust Nice Person or $100? Disconnected trx signing devices are simple, cheap, and have *fewer* costs. Note I do not say none of the costs, but it is significantly less and at least we don't trust the user's browser, the user's browser can be any platform (MacOS X, Linux, FreeBSD, Win95, XP, Vista), we don't end up supporting the user's desktop, and we don't need to train the users so much. That's why smart cards will not be used if the Bank has done a proper side-by-side comparison, and compared the relative risk versus cost. Smart cards (and anything which requires platform support) are less secure, less trustworthy, take more effort, and cost more. thanks, Andrew On 23/07/2006, at 3:42 PM, mikeiscool wrote: No I disagree still. Consider a smart card. Far easier to use then the silly bank logins that are available these days. Far easier then even bothering to check if the address bar is yellow, due to FF, or some other useless addon. smime.p7s Description: S/MIME cryptographic signature ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] bumper sticker slogan for secure software
Actually, it is a myth. For every non-trivial system, there are business pressures on resourcing, deadlines, and acceptable quality (pick any two). Once a business has set their taste for risk, it makes no sense to spend say $10m on security controls on a product and delay it for six months which may only bring in $2m in revenue in total, or none at all if the company runs out of money to bring it to market. At the moment, most companies neither accept or assign the risk, enumerate the risk correctly, nor take adequate steps to eliminate as much risk as possible. We need to improve all three aspects. Even in a perfect world, there will still be bugs and security defects. Let's make sure that the remaining ones are really hard to exploit, and when the exploit happens, not much loss occurs. thanks, Andrew On 19/07/2006, at 10:59 AM, mikeiscool wrote: Absolute security is a myth. no it isn't. pretending it is a 'myth' is an attempt by sloppy programmers and designers to explain away the reasons for their applications failing. smime.p7s Description: S/MIME cryptographic signature ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] bumper sticker slogan for secure software
Best for older cars... My other car is a bit more secure Best for Volvos (or pick another high safety brand): I wish my finance systems are as safe as this car Honk if you want secure software Who has your data? Ask for secure software next time thanks, Andrew smime.p7s Description: S/MIME cryptographic signature ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
[SC-L] OWASP PHP Top 5 Announcement
OWASP is pleased to announce the immediate availability of the OWASP PHP Top 5. The OWASP Top 5 is an education piece which provides up to date advice to PHP developers, hosters, and other PHP users. The PHP Top 5 is produced by the OWASP PHP Project. The PHP Top 5 is based upon attack frequency in 2005 as reported to Bugtraq. This information is a valuable insight into the most devastating attacks against the world's most popular web application framework. In 2005, OWASP collaborated with SANS to research and write a completely new PHP section for their successful SANS Top 20 2005. The OWASP PHP Top 5 is the full unabridged text, updated to reflect recent XSS attacks and SQL injection vectors. OWASP PHP Top 5 http://www.owasp.org/index.php/PHP_Top_5 OWASP PHP Project http://www.owasp.org/index.php/Category:OWASP_PHP_Project smime.p7s Description: S/MIME cryptographic signature ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Re: [WEB SECURITY] On sandboxes, and why you should care
Dinis, Sandboxing prevents a machine from having bad system() and buffer overflows causing system compromise. Sure that's bad enough. However, sandboxing does not prevent: * all types of cross-site scripting * SQL injection * Command injection via SQL injection (xp_cmdshell and similar Oracle library calls) * Command injection as the limited capabilities allowed by the sandbox ... until the attacker can work out how to get out of the sandbox, say via a friendly unpatched service or tunnelling terminal services outbound, or similar * LDAP injection * XML injection * authentication attacks, such as brute forcing etc * failure of authorization code to protect controlled resources, operations or transactions * file operations on the files the app is authorized to touch, often quite sensitive in themselves * second order injections (ie batch integrity issues) * middleware attacks * web service attacks * SMTP attacks - ie formmail.pl - if it's badly written, there's no way a sandbox will help * or the usual sorts of transactions which can lose a business money, like ship X widgets to Y (phishing). Sandboxing reduces but does not eliminate the risk that the app server process can go ahead and destroy the rest of the box, which is important in a shared environment. But if the attacker can run arbitrary code on your host, it's just a matter of time before they work out how to go from loading netcat to 0wning you. That's why PHP's safe mode is not really all that safe and in fact, is more than occasionally easier to 0wn than the normal way. For example, look at the code that Microsoft suggests for users of the SQL Server Reporting Services add-on: http://support.microsoft.com/?kbid=842419 They recommend giving any SQL-calling code PermissionState.Unrestricted access to the SQL server. Guess what? The permission flood gates are now opened, and SQL injections are all back if there's dynamically constructed queries in the code. Plus, those instructions are so long winded, if that's what is required for every assembly which asserts CAS permissions, there is the reason it's not done. Developers are under the pump, and unless it's easy, trivial and automatic, it will not be done. Sandboxing and partial trust is a defense in depth mechanism that solves a small subset of issues and has the potential to reduce damage from other types of attack as long as keys to the kingdom are not granted by the asserted permissions. It would be nice if it was on by default and programmers used it, but I'm not losing sleep over it. If I come across code which needs help with cross-site scripting or injections or worse, a process which is easy to conduct fraud with, I will fix that before telling them to turn the verifier on or insert code to demand permissions from the underlying CLR or VM. thanks, Andrew On 24/05/2006, at 8:34 AM, Dinis Cruz wrote: (sorry for the long time that it took for this response, see comments inline) Stephen de Vries wrote: Hi Dinis, I think you're overestimating the effectiveness of a sandbox in preventing common web app vulnerabilities, and you're instead focussing on the tiny fraction of specific attacks that can be stopped with sandboxes. Well Stephen, I would argue that you are underestimating that effectiveness :) I also don't think that I am focusing on a tiny fraction of specific attacks. Sandboxes have the capability to resolve most of the current types of attacks we have today. And the ones that it is not able solve, it will make them easy to detect. In fact, I would argue that Sandboxing could actually make the 'Sandboxed Application' more simple, effective, cheaper to develop and easier to audit. The fundamental point of departure between our points of view is that I would argue that, the crown jewels are already inside the sandbox! I think that you are thinking of a unidimensional Sandbox model similar to the one created by the Operating system between user- land process and kernel, or the one implemented by .Net / Java for mobile code executed on a web browser. In the solution that I am envisioning, you will have multiple Sandboxes, one inside the other, separated by very clearly defined layers (the input choke points / attack surface) where each sandbox is allocated privileges accordingly to what it needs to get the job done (principle of least privilege), the amount of trust that we have in that code (Code Access Security) and the identity used to executed it (Role Based Security). Unfortunately the Partial Trust Sandboxes that currently exist on the .Net Framework (namely Medium Trust) are not good examples of Sandboxes since they still allow the creation of easy exploitable Asp.Net code (i.e. the security vulnerabilities that you mention below would still occur on a web application executed under Medium Trust). So spending time and effort to
[SC-L] Java integer overflows (was: a really long topic)
I'm not talking arbitrary code execution, I'm talking about odd code
paths, bizarre outcomes, and DoS.
For example (found via 19 Sins, Viega, Howard and LeBlanc):
http://seclists.org/lists/bugtraq/2004/Nov/0097.html
I know Michael reads webappsec, he may have more examples.
In my own code testing, I look for silly behaviors if a user can
insert a large or negative number. You'd be surprised how often it
occurs. There is no excuse not to include basic range checks when
performing data validation.
thanks,
Andrew
On 29/03/2006, at 2:30 PM, [EMAIL PROTECTED] wrote:
No you dont.
Arrays are all bounds checked; ..., that is, the following code will
throw an exception:
class Foo {
static {
int[] m = new int[2];
System.out.println(m[34]);
}
}
What do you mean by overflow? Do you mean this?
class Foo {
static {
int m = Integer.MAX_VALUE;
int k = Integer.MAX_VALUE + Integer.MAX_VALUE;
System.out.println(m);
System.out.println(k);
System.exit(0);
}
}
if so, I don't see how that is an issue.
-- Michael
On 3/29/06, Andrew van der Stock [EMAIL PROTECTED] wrote:
This is not quite true.
Java does not prevent integer overflows (it will not throw an
exception). So you still have to be careful about array indexes.
Andrew
smime.p7s
Description: S/MIME cryptographic signature
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
Re: [Owasp-dotnet] Re: [SC-L] Is there any Security problem in Ajax technology?
Yes! :) I am speaking at the OWASP EU conference in Belgium (I hope people speak English 'cos my French is now quite appalling) at the end of May, and I have a paper submission for O'Reilly's OSCON in early July. I am still mulling over whether to submit a proposal to BlackHat as although I love junkets, I can't do too many - I have to work as well :) Next, once the chapter is released, it will be a major new addition to the OWASP Guide 2.1, and I'm sure we'll be doing something about promoting it at that point. There's not really any technology required to secure Ajax; it's all about the architecturally correct location of authorization, validation and preventing injection attacks. There's no magic technical bullet, WAF, or similar which can help fix these things. The issues with Ajax aren't really new, it's just that devs are introducing new classes of vulnerability because they have forgotten the hard lessons learnt in the past. thanks, Andrew On 15/03/2006, at 12:33 PM, Eric Swanson wrote: My question: How does OWASP plan to educate the public regarding security concerns raised by AJAX and, indeed, any new methodology or technology and what is its plan to develop tools that translate this education into practice? *AJAX and related methodologies should be addressed by all groups within OWASP, so I'm guessing that the .NET group isn't the only group actively discussing it. (AFLAX - a Flash version also raises the same concerns.) smime.p7s Description: S/MIME cryptographic signature ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
[SC-L] Fwd: Security problems with Ajax
Hi there, I replied to Kentaro privately before I was subscribed to this list. The OWASP Guide 2.1 Ajax chapter is about 80% done and 80% to go. I have some serious vulnerabilities to report to a few vendors, research to be included in the paper, such as JSON injection and so on, and peer review from an accessibility expert (as I'm not qualified in this area). My slide deck from the OWASP Melbourne chapter meeting in February is also useful: http://www.greebo.net/owasp/ajax_security.pdf (PDF, 1.8 MB) Here is my message to Kentaro-san: Begin forwarded message: From: Andrew van der Stock [EMAIL PROTECTED] Date: 7 March 2006 2:54:36 AM To: kentaro.arai at hidden Subject: Security problems with Ajax Kentaro, In short, yes! :) I am researching and writing a new chapter on Ajax security for the OWASP Guide which will be out as soon as it's been properly reviewed. In my travels, I've found many implementation issues surrounding how Ajax toolkits are used. In particular: a) security architecture. Where to start... please read the chapter when it comes out b) sending to a second, disassociated server prevents secure state, such as authorization from being shared. This usually leads to really poor decisions about state management and application design c) insecure client-side state storage - including authorization decisions d) client-side authorization (!!!) or non-existent authorization (!!!) e) new classes of injection attacks (which I call Ajax injection as a meta-class of attack, but are in fact a multitude of injection attacks including existing issues such as Javascript code injection (as per GMail last week) and basic XSS, through to JSON injection, which is a new one) due to a lack of care with encoding, decoding, and in general simply not thinking things through f) insufficient validation on the server, particularly when Ajax calls web services, and even more so when Ajax calls enterprise service buses (SOA) publishing 40 year old COBOL code which has never been tested for XML node injection before g) insufficient business rule validation. This is true of normal apps as well, but it is particularly prevalent with Ajax apps as for some strange reason they believe Ajax is secure magic pixie dust. I've got a few demo vulnerabilities to report to various places before I can speak about these in the open. h) GET request mania. I know that someone here posted something about REST, but honestly, GET methods is a privacy nightmare for many firms who must go out of their way to prevent private information leaking into third party systems like ISP caches or browser history on Internet kiosks. Only a few toolkits had clear documentation on how you can change to using POST data... which surprisingly includes CPaint, one of the first Ajax toolkits to be exposed as insecure. Version 2.0.x of CPaint is s much better. h) not particularly security related, but is compliance related - Ajax frameworks are in general completely inaccessible. They fail WAI validation miserably, do not provide alternate accessible paths, and rarely prompt screen readers to refresh the screen. Many are fixed pixel sizes and work in new ways which makes using assistive technologies impossible as they don't know how to handle this bag o' pixels masquerading as an application. I am getting this section peer reviewed by an accessibility specialist, but as it's illegal to produce inaccessible applications unless it's a justifiable hardship (gee, spending 20%-90% more to create a glitzy interface over an accessible one will go down well with our equal opportunity legal beagles). Ajax CAN be accessible. But with few exceptions, it is not. In some hard core cases, the vendors must really hate and despise disabled users and users with high DPI screens. I have one major commercial Ajax vendor suite that acts like its own desktop UI that *crashes* the browser when you try to increase the font size to something readable. I will name names soon if they don't get their act together. Completely and utterly unacceptable. In short, Ajax can be made secure, but in general it is not - application writers are at worse than security square one with most toolkits. The architecture alone forces many poor choices upon application authors, and if they are unaware of security issues, they will create insecure and unsecurable web applications. thanks, Andrew ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
