WebApplicationSecurity concerns itself with the subject of InformationSecurity for WebApplication and WebServices. (In this context, WebServices includes RestArchitecturalStyle implementations, and also special setups such as ComInternetServices, VirtualPrivateNetwork''''''s and MobileCommerce.) SecurityManagement in this context include: * physical security * security conscious users * NetworkSecurity * TransportSecurity * ApplicationSecurity Charateristics of the environments where WebApplications operate * use of HTTP protocol * information may be transmitted through insecure or otherwise vulnerable connections * restrictions may exist (e.g. a FireWall) that control/limit access * there may not be control over the software used on client applications '''ApplicationSecurity has these three overlapping aspects:''' from LincolnStein 88 Brisbane presentation * System security * Client privacy * Document confidentiality Issues * scalability of security solutions * network eavesdropping and man-in-the-middle attacks * CrossSiteScriptingExposure * DistributedDenialOfService * code injection (antipattern to SoftwareFaultInjection) * SocialEngineering such as phishing (identity thefts) * cultural considerations and emotional costs of tougher security measures Security technologies available for use include * IpSec or OpenVpn: VirtualPrivateNetworking * SecureSocketsLayer * PublicKeyInfrastructure * KerberosProtocol * HttpsProtocol Security techniques * port knocking * DMZ ''Security is a process, not a product'' from BruceSchneier ---- '''Common risk areas requiring attention''' From Payment Card Industry document at http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf * 6.5.1 Unvalidated input * 6.5.2 Broken access control (e.g., malicious use of user IDs) * 6.5.3 Broken authentication/session management (use of account credentials and session cookies) * 6.5.4 Cross-site scripting (XSS) attacks * 6.5.5 Buffer overflows * 6.5.6 Injection flaws (e.g., SQL injection) * 6.5.7 Improper error handling * 6.5.8 Insecure storage * 6.5.9 Denial of service * 6.5.10 Insecure configuration management. ---- '''WebApplicationSecurity News & Developments''' '''Nov04''' * ''First serious JavaLanguage (all OS platforms) flaw can only be solved by upgrade '' see http://news.zdnet.com/2102-1009_22-5464872.html?tag=printthis * ''Concerns over SecureSocketsLayer getting compromised by MalWare '' see http://www.computerworld.com/printthis/2004/0,4814,97936,00.html * ''Java security problems (both MS & Sun) and vulnerabilities at multiple OS a hot topic. Example article at'' http://www.computerweekly.com/print/ArticlePrinterPage.asp?liArtID=135316&liFlavourID=1 * ''Microsoft's answer to phishing:Two IDs'' http://news.com.com/2102-1029_3-5457381.html?tag=st.util.print '''Sep04''' * ''email SPF security compromised'' http://news.com.com/2102-1029_3-5357269.html?tag=st.util.print '''Aug04''' * ''SSL flaw in Netscape library'' http://p2pnet.net/story/2250 ---- '''Intranet, Extranet and Internet''' There are differences in the security requirements for the above. Extranet is meant to include only external connection points that are relatively few in number and can be managed individually. ''(Unfixable) Browser exposure'' But workarounds exist. See a demo at http://www.schneier.com/blog/archives/2005/02/unicode_url_hac_1.html ---- '''Platform considerations''' Aug05 info. LampEnterpriseSolutions is said to have misses in instances where SecureSocketsLayer WebApplication is required. This is noted by a MS manager who is promoting use of MicrosoftExpress instead. ''What do you mean by "is said to have misses?"'' ---- '''And then there are WirelessLocalAreaNetworks''' ''Such devices need to be hardened, repeatedly and diligently scanned for presence of malware''. As at mid 2004, security measures again falls apart when one or more devices on the network is Wireless. These wireless devices are typically mobile, they can go missing for a period of time, and returned with implanted moles. Or while taken to work on public transport, these could exchange information with another wireless device from a different company / network. ---- '''Competing or Complementary schemes''' ''SecureSocketsLayer compare to IpSec'' - from Computerworld Aug04 article Used in conjunction with a VirtualPrivateNetwork. It is more costly, harder to manage (e.g. more security provisions required as it uses Layer3) and more difficult to connect (e.g. susceptible to NAT problems). As at 2004 it has more than twenty times usage (in dollar terms) than SSL setups. VPN schemes (commonly IpSec based) often include a firewall and numerous other security functions including intrusion detection, content scanning, web filtering, etc. Thus remote access is only one of many usages a VPN setup can be put to use. The SSL schemes often have more limited applications, and there are significant variances between support for applications from different vendors. Note, that most SSL schemes are _not_ vpn's, despite their vendors insistence to the contrary. Instead, they are usually ApplicationGateway''''''s, or a web proxy. A notable exception is OpenVpn, which is a true vpn using SSL to provide authentication, encryption and integrity. A VPN is a network link or tunnel, usually either on the Ethernet or IP layers, and specifically not on the application layer. ---- In practice the biggest security flaw of most web operations that is not introduced by poor server-side programming - which could eat up a big page by itself, or failing to keep up to date with patches, is allowing telnet or ftp connections to servers. Don't allow any privileged connections to your servers that don't pass over an encrypted connection. Teach your people to use ssh and scp. One thing to remember about complicated security measures is that if you don't have the resources to have an employee who is really up to date with the details you are likely to misconfigure them, in which case you would have been better off not using them in most cases. Also, the vast bulk of compromises are internal - worth bearing in mind. (And in case you think the ssh/scp thing is not that important... I have spent a lot of time in the last year thinking about how to use unsecured communications to make money - I'm not planning on doing it, as I make a good living as it is without running the risk of going to jail, but.... I'm pretty sure that I could safely make an enormous amount of money by taking advantage of ''unencrypted data channels'', if I wanted to. I have a criminal mind, in a mostly law-abiding body, I guess. I am pretty confident that there are other people out there who lack that impedance mismatch.) '''24-90-12-252.nyc.rr.com''' I am aware (in a general sense) of schemes using unsuspecting computers in foreign lands to plant "moles", which will be activated later on for SocialEngineering or related schemes. Are you referring to something similar? '''Do you have a weblink''' that an average IT person, not a security specialist, can understand and take measures to fortify the security barrier? -- dl OK - well, I'm a bit leery of explaining exactly what I mean - my purpose is not to give people a blueprint for committing IT crimes, and I wouldn't want anyone to hold me responsible for doing so, but... this stuff is actually pretty obvious, I think... which is why I would be surprised if it weren't being done. You're certainly right that a lot of moles (I would call them Trojans) are being installed all the time on computers, around the world - in this case, "foreign" has little meaning - I assume you mean outside the US by that, but in fact a lot of the machines used to send spam, and perform DDOS attacks are within the US- the perpetrators may be largely in countries that it's hard to extradite from... this just proves that they lack really good criminal minds :). Smart criminals commit crimes that don't leave traces... breaking into someone's computer leaves lots of them. Smart criminals look for really large, entirely safe scores. Using other people's computers to send spam, or blackmail a company, is a very small, stupid score... and that's why you hear about it - you don't ever hear about the things that smart criminals do. My point is mostly this: information is very valuable these days - especially certain types of information. If you had perfect ESP, think of the things you could do... Now think about how information is transmitted in the modern world- cause information that is not shared between at least two people is hardly information at all. People are sloppy, and really sensitive information is transmitted over insecure channels all the time. And it is possible to eavesdrop on some of these channels without ever cracking anything... think WiFi and a Starbucks in downtown Manhattan. This is kind of offtopic to this page now, but - it is parallel to website security - don't transmit your passwords over unencrypted channels. It's really easy to flip an ethernet interface into promiscuous mode, and it's really easy to grab telnet and ftp passes from there. And given the number of people administering sites over home cable connections, and the number of people that might be on your subnet... and watch your WiFi too. Also, remember that unless you are high profile securing your website is a lot like securing your car - if you make it hard to get in, people will find a softer target. If marketing would let me, I'd firewall off port 80. Since I can't do that, I firewall every other port off, even the ssh port, and only allow connections from known addresses. Layer security - admin interfaces should be firewalled against unknown IPs, _and_ authenticated at the user level. And if you can toss in another level, without driving your users crazy, do it. Turn off all unnecessary services, and patch the ones you have to keep on- and firewall them off too if you can. It's the simple stuff that bites you. But always remember that most security breaches come from inside. (Particularly if you are unfairly terminated :) ). ---- Tips for typical web security: * Check web parameter values inserted into SQL statements to make sure they are not extra SQL code. This may involve encoding quotes. * Don't rely purely on JavaScript for validation. JavaScript can be turned off or fudged on the client-side. * Be careful how passwords and user-ID's are passed around between web modules. Use a framework's security system or encryption. * Turn "variable overriding" off. Some web tools let web parameters override program variables as a convenience, but this is a security risk for public websites. ---- '''Resources''' * WhomDoYouTrust? http://www.econtentmag.com/Articles/ArticlePrint.aspx?ArticleID=7361&ContextSubtypeID=11 * Info on security issues not limited to WebServices: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh12.asp * Online free book on Linux security programming http://www.dwheeler.com/secure-programs/ * Intro to cgi security http://www.extropia.com/tutorials/security/ * renowned W3C FAQ by LincolnStein http://www.w3.org/Security/faq/ * Guide from Open Web Application Security Project http://alex.netwindows.org/owasp_guide/guide.html * mobile security brief (2004) at http://www1.netsec.net/content/securitybrief/archive/2004-10_MobileSecurityThreats.pdf * Linux secure programming LinuxDocumentationProject guide at http://db.ilug-bom.org.in/Documentation/HOWTO/Secure-Programs-HOWTO/introduction.html ---- CategorySecurity