As far as I can see the offerings fall into two categories – scanning services such as McAfee, Comodo, etc. and tools such as Burp Proxy, HP’s WebInspect,CodeScan, etc.
In an ideal world, I’d use something that actively scanned a certain URL (the target being a LAMP stack) on a daily basis (or as required if it’s a standalone tool), but I’m a bit wary of standalone tools in terms of their coverage and frequency of updating. (The ‘remote’ scanners such as McAfee are presumably updated as required.)
I’ve also had issues with some standalone tools (can’t remember which one unfortunately) that managed to get themselves lost within our URL rewriting system (there’s a facetted search in play, so you can imagine things get fairly deep on the URL front).
As such, I’m just wondering what experiences people have had with the offerings out there and whether the standalone tools stack up against the scanning services.
(Incidentally, I'm aware of Penetration testing tools - I'm just wondering if the situation has changed since then)
I have done penetration testing and exploit development. I can tell you from first hand experience that hacking isn't just firing off some tool. Sometimes tools can make life easier, but if you don't know what you are doing then a tool isn't going to help.
If you want to KNOW that your system is secure then you need to higher a skilled hacker to break in. The PCI-DSS is a certification required for credit card processing which mandates that you have regular penetration testing conducted on your server. Conducting regular penetration testing is something that you should adopt if you want to have a very secure server.
A very good security measure for web servers is a Web Application Firewall (WAF). WAFs are also required by the PCI-DSS. Mod_security is free and open source WAF. Mod_Security can be used to prevent hundreds of different types of attacks. A WAF can be a nightmare for a penetration tester or would be hacker.
Related
I have been programming a small e-commerce platform to sell jewelry.
Initially I wanted to make it web3 compatible ( accept meta mask payments ) and given that I work as a dev I wanted to take the DIY approach as opposed to platforms like Shopify specifically.
Now that I’m getting closer to finishing the website , I contemplate to myself - should I just switch to using Shopify instead ? My contemplation stems from unknown vulnerabilities that I am anticipate ..
My site uses Stripesnd paypal for payments. I don’t save any other data besides order info and shipping address .
Is there any underlying vulnerabilities that Shopify takes care of that I’m not thinking of ?
It seems simple enough to take payments on a site but I have a feeling I am not thinking about some major implications of not using a platform like Shopify .
On one hand I’d really like to use my own website given all the time I’ve spent making it ( also like my front end design better than any template I’ve seen ) so this post is for people to give me their perspective on both pros and cons so I can decide whether I just neeed to dump my work and start over with Shopify or continue on the way forward with DIY coming out as hero ;)
Thanks In advance fam
It is perfectly possible to make your own website and make it secure enough, somebody made Shopify too after all. :) It is also easily possible to leave vulnerabilies in your code that then get exploited. The problem is that if you don't have a good grasp of what you should have even looked at, it will be quite challenging to actually get it right.
You should be aware of potential code level vulnerabilities, and use secure coding and architecture principles to structure and code your website. OWASP is a great resource that helps with learning about those. Higher level principles include things like least privilege, segregation of duties, defense in depth, minimizing attack surface, secure defaults, failing securely and so on. Actual code level vulnerabilities include things like SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), tampering with parameters, session management errors, authentication or authorization errors and so on, there is a lot of these. And your 3rd party libraries that you included can (and will) also have some of these, how will you discover that, and will you have the capacity to keep up with latest versions?
When hosting your own service (even in an IaaS cloud environment like AWS EC2), that brings its own challenges in terms of security too - you need to care about the ops side of security as well. Things like would you even notice if there's an attack? Would you know what to do if a customer called with their money spent on things they didn't buy? Would you have forensic evidence to prove if they are actually lying? :)
You can use tools to scan for some of these vulnerabilities, but that will never be comprehensive - actually, nothing will. Automated tools are very useful, but will miss a lot of things. You can also buy penetration testing services, some of those are really good (and some not), they will find vulnerabilities the same way attackers would - but those are quite expensive.
However, having said all this, the most important thing is to keep your defenses proportionate to the risk. This basically means you don't want to spend more on securing your website than the maximum amount you may lose in case of a compromise. Outsourcing payments to Stripe or Paypal is a great start, because if you have the integration correctly set up, you likely already limited the maximum possible loss quite a bit.
So should you code an ecommerce website yourself, and sell stuff? In the light of the above, it's very opinionated, but I think why not, just consider the above, manage your risks, learn about potential vulnerabilities, mitigate them the best you can, and prepare for things to go wrong. In the end, it's probably cheaper to just use a ready-made service, though a lot less fun. :)
I would say, you should... and you can use any SaaS eCommerce platform: Shopify or BigCommerce or Snipkart without giving up your DIY custom features, because those platforms can be used as a headless eCommerce platform.
This way you don't have risks around managing backend and data (platform will do this, and not loosing the custom features and fine-tuned customer experience you implemented yourself)
We want to regularly test our web apps for vulnerabilities - we have a BurpSuite licence but would like to look into the possibility of using an online solution.
Benefits as we see them:
Little/no staff training required
It's always up to date (checking the latest known vuns)
It may be more cost-effective
Has anyone used such a solution before? How was the experience over manual testing with a local app such as BurpSuite?
Does your regular testing involve running purely automated scans or manual analysis using BurpSuite?
A cloud-based scanner isn't going to offer as much interactivity as running BurpSuite locally. Manual analysis is important for analyzing design issues, authorization problems, or logic errors. What a fully automated scanner will (or should) do is take care of tedious tests for vulns like SQL injection and XSS. (Think of it as finding implementation problems rather than design problems.)
A cloud-based scanner could be a drop-in replacement for BurpSuite scans you're running "out of the box" -- i.e. not using much configuration. But it should never the less complement, not replace, good manual testing. This can be a benefit cost-wise.
While a cloud-based scanner can be "always up to date", in reality there are very few new web vulns. For example, the OWASP Top 10 has only changed a little in the last 7 years. The updated vulns will help if you're mostly using open source or commercial web apps, but they won't have any bearing on the apps you build in house.
(FYI, my perspective comes from working on a cloud-based scanner.)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
in these days, i'm interested in software security. As i'm reading papers i see that there are many attacks and researchers are trying to invent new methods for softwares to get more secure systems.
this question can be a general including all types of attacks.There are many experienced programmers in SO, i just want to learn what are using to check your code against these attacks ? Is there any tools you use or you don't care ?
For example i heard about static/dynamic code analysis and fuzz testing.
SQL injection attacks
Cross Site Scripting
Bufferoverflow attacks
Logic errors
Any kind of Malwares
Covert Channels
... ...
thanks
I'm going to focus on web application security here...
Really you want to get used to manually trawling through a website/application and playing with various parameters etc. so proxy tools are of great help (they allow you to capture and interact with forms, before they reach the server):
LiveHTTPHeaders - FireFox plugin.
Burp Proxy - Java based.
Obviously there becomes a point where manually crawling a whole website becomes rather time consuming/tedious and this is where automated scanning tools can be of help.
Black box:
WebSecurify - not used it but it's been created by a well known web app security guy.
Skipfish - Google released this recently so it's probably worth a look.
And there are many other commercial tools: WhiteHat Sentinel, HP Web Inspect and probably many others I can't remember.
White box:
A lot of the academic research I've seen is related to static code analysis tools; I've not used any because they all focused on PHP only and had some limitations.
Other resources:
ha.ckers.org - great blog, with an active forum related to web app sec.
OWASP - as perviously mentioned, there are lots of insightful articles/guides/tutorials here.
If you want to learn more about manually attacking sites yourself the Damn Vulnerable Web App is a nice learning project. By that I mean, it's a web application that is written to be deliberately insecure, so you can test your knowledge of web application security vulnerabilities legally.
I wrote a black box scanner in Perl for my third year dissertation which was quite an interesting project. If you wanted to build something yourself it really just consisted of:
crawler
parser
attacker
Something that you haven't mentioned but I think is important: code reviews.
When you're just trying to implement something as fast as you can it is easy to overlook a security issue. A second pair of eyes can pick up many problems or potential problems, especially if the reviewer is experienced at spotting typical security holes.
I believe that it is possible in many cases to do manual code reviews without special tools. Just sit together at the same computer or even print out the code and do the review on the paper copy. But since you specifically asked for tools, a tool to help with manual code review is Rietveld. I haven't used it myself, but it is based on the same ideas used internally at Google (and written by the same guy, who also happens to be the author of Python).
Security is definitely a concern and developers should at least be aware of common vulnerabilities (and how to avoid them). Here are some resources that I find interesting:
OWASP Top 10 for 2010
OWASP Guide for Secure Web Applications
OWASP Testing Guide v3
There are 2 types of software defects that can cause security problems: implementation bugs and design flaws.
Implementation bugs usually appear in a specific area in the code, they are relatively easy to detect and (usually) not too complicated to fix. You can detect (most) of these with automated tools that do static code analysis (tools like Fortify or Ounce) although these tools are expensive. With that said, you still have to remember that there are no "silver bullets" and you cannot not blindly rely only on the tool output without some sort of manual code review to confirm/understand the real risk behind the issues the tool reports.
The other problem is design flaws, that's another story. They are usually complex issues that are not consequence of a mistake in the code but poor choice in the design or architecture of the application. Those cannot be identified by an automated tool and really can only be detected manually, by a code/design/architecture review. They are usually very hard and expensive to fix passed the design phase.
So I recommend, reviewing your code for implementation bugs that can have impact on security (code review using automated tools like Fortify/Ounce + manual review of tool results) and reviewing your design for security flaws (no tools for this, has to be done by someone who knows about security).
For a good read on software security and the complexity behind designing secure software, check Software Security: Building Security In, by Gary McGraw (amazon link)
I use tools to aid in the hunt for vulnerabilities, but you can't just fire off some test and assume everything is okay. When I am auditing a project I look at the code and I try and get a feel for the programmers style and skill level. If the code looks messy then chances are they are a novice and they will probably make novice mistakes.
It is important to identify security related functions in a project and manually audit them. Tamperdata is very helpful for manual auditing and exploit development because you can build custom http requests. A good example for manual auditing for PHP is: Are they using mysql_real_escape_string($var) or are they using htmlspecialchars($var,ENT_QUOTES) to stop sql injection? (ENT_QUOTES doesn't stop backslashes which is just as dangerous as quote marks for mysql, mssql is a different story.) Security functions are also places for "Logic errors" to crop up, and no tool is going to be able to detect this, this requires manual auditing.
If you are doing web application testing then Acunetix is the best testing tool you can use. Wapiti is a very good open source alternative. Although any tool can be used improperly. Before you do a web application test make sure error reporting is turned on, and also make sure you aren't suppressing sql errors, such as with a try/catch.
If you are doing Automated Static Code Analysis for vulnerabilities such as Buffer Overflows then Coverity is the best tool you can use(Fortify is nearly identical to Coverity). Coverity costs tens of thousands of dollars, but big names like the Department Of Homeland Security uses it. RATS is a open source alternative, although Coverity is far more complex of a tool. Both of these tools will produce a lot of false positives and false negatives. RATS looks for nasty function calls, but doesn't see if its still safe. So RATS will report every call to strcpy() strcat() sprintf(), but these can be safe if for instance you are just copying static text. This means you will have to dig though a lot of crap, but if you are doing a peer review then RATS helps a lot by narrowing the manual search. If you are trying to find a single exploitable vulnerability in a large code base, like Linux, then Rats isn't going to help much.
I have used Coverity and their sales team will claim it will "detect ****ALL**** vulnerabilities in your code base." But I can tell you from first hand experience that I found vanilla stack based buffer overflows with peach that Coverity didn't detect. (RATS did however pick up these issues, along with 1,000+ other function calls that where safe...) If you want a secure application or you want to find an exploitable buffer overflow then Peach is the platform tool you can use to build the tools you need.
If you are looking for more exotic memory corruption issues such as Dangling Pointers then Valgrind will help.
There's bunch of web application security scanners in the market
Take a look at this list:
WASC - Web application security scanner list and Netsparker Community Edition : which is the free version of Netsparker.
A tool doesn't know if your code is insecure.
Only you do (and the attackers).
At best the tool will spot a few vulnerabilities of one type in your code and make you realize you never protected against that type of vulnerability, but you will still have to go clean up all the instances the tool missed.
As part of a PCI-DSS audit we are looking into our improving our coding standards in the area of security, with a view to ensuring that all developers understand the importance of this area.
How do you approach this topic within your organisation?
As an aside we are writing public-facing web apps in .NET 3.5 that accept payment by credit/debit card.
There are so many different ways to break security. You can expect infinite attackers. You have to stop them all - even attacks that haven't been invented yet. It's hard. Some ideas:
Developers need to understand well known secure software development guidelines. Howard & Le Blanc "Writing Secure Code" is a good start.
But being good rule-followers is only half the point. It's just as important to be able to think like an attacker. In any situation (not only software-related), think about what the vulnerabilities are. You need to understand some of those weird ways that people can attack systems - monitoring power consumption, speed of calculation, random number weaknesses, protocol weaknesses, human system weaknesses, etc. Giving developers freedom and creative opportunities to explore these is important.
Use checklist approaches such as OWASP (http://www.owasp.org/index.php/Main_Page).
Use independent evaluation (eg. http://www.commoncriteriaportal.org/thecc.html). Even if such evaluation is too expensive, design & document as though you were going to use it.
Make sure your security argument is expressed clearly. The common criteria Security Target is a good format. For serious systems, a formal description can also be useful. Be clear about any assumptions or secrets you rely on. Monitor security trends, and frequently re-examine threats and countermeasures to make sure that they're up to date.
Examine the incentives around your software development people and processes. Make sure that the rewards are in the right place. Don't make it tempting for developers to hide problems.
Consider asking your QSA or ASV to provide some training to your developers.
Security basically falls into one or more of three domains:
1) Inside users
2) Network infrastructure
3) Client side scripting
That list is written in order of severity, which opposite the order to violation probability. Here are the proper management solutions form a very broad perspective:
The only solution to prevent violations from the inside user is to educate the user, enforce awareness of company policies, limit user freedoms, and monitor user activities. This is extremely important as this is where the most severe security violations always occur whether malicious or unintentional.
Network infrastructure is the traditional domain of information security. Two years ago security experts would not consider looking anywhere else for security management. Some basic strategies are to use NAT for all internal IP addresses, enable port security in your network switches, physically separate services onto separate hardware and carefully protect access to those services ever after everything is buried behind the firewall. Protect your database from code injection. Use IPSEC to reach all automation services behind the firewall and limit points of access to known points behind an IDS or IPS. Basically, limit access to everything, encrypt that access, and inherently trust every access request is potentially malicious.
Over 95% of reported security vulnerabilities are related to client side scripting from the web and about 70% of those target memory corruption, such as buffer overflows. Disable ActiveX and require administrator privileges to activate ActiveX. Patch all software that executes any sort of client side scripting in a test lab no later than 48 hours after the patches are released from the vendor. If the tests do not show interference to the companies authorized software configuration then deploy the patches immediately. The only solution for memory corruption vulnerabilities is to patch your software. This software may include: Java client software, Flash, Acrobat, all web browsers, all email clients, and so forth.
As far as ensuring your developers are compliant with PCI accreditation ensure they and their management are educated to understand the importance security. Most web servers, even large corporate client facing web servers, are never patched. Those that are patched may take months to be patched after they are discovered to be vulnerable. That is a technology problem, but even more important is that is a gross management failure. Web developers must be made to understand that client side scripting is inherently open to exploitation, even JavaScript. This problem is easily realized with the advance of AJAX since information can by dynamically injected to an anonymous third party in violation of the same origin policy and completely bypass the encryption provided by SSL. The bottom line is that Web 2.0 technologies are inherently insecure and those fundamental problems cannot be solved without defeating the benefits of the technology.
When all else fails hire some CISSP certified security managers who have the management experience to have the balls to speak directly to your company executives. If your leadership is not willing to take security seriously then your company will never meet PCI compliance.
Anyone have suggestions for security auditing of an .NET Web Application?
I'm interested in all options. I'd like to be able to have something agnostically probe my application for security risks.
EDIT:
To clarify, the system has been designed with security in mind. The environment has been setup with security in mind. I want an independent measure of security, other than - 'yeah it's secure'... The cost of having someone audit 1M+ lines of code is probably more expensive than the development. It looks like there really isn't a good automated/inexpensive approach to this yet. Thanks for your suggestions.
The point of an audit would be to independently verify the security that was implemented by the team.
BTW - there are several automated hack/probe tools to probe applications/web servers, but i'm a bit concerned about whether they are worms or not...
Best Thing to do:
Hiring a security guy for source code analysis
Second best thing to do hiring a security guy / pentesting company for black-box analysis
Following tools will help :
Static Analysis Tools Fortify / Ounce Labs - Code Review
Consider solutions such as HP WebInspects's secure object (VS.NET addon)
Buying a blackbox application scanner such as Netsparker, Appscan, WebInspect, Hailstorm, Acunetix or free version of Netsparker
Hiring some security specialist is so much better idea (will cost more though) because they won't only find injection and technical issues where an automated tool might find, they will also find all logical issues as well.
Anyone in your situation has the following options available:
Code Review,
Static Analysis of the code base using a tool,
Dynamic Analysis of the application at run time.
Mitchel has already pointed out the use of Fortify. In fact, Fortify has two products to cover the areas of static and dynamic analysis - SCA (static analysis tool, to be used in development) and PTA (that performs analysis of the application as test cases are executed during testing).
However, no tool is perfect and you can end up with false positives (fragments of your code base although not vulnerable will be flagged) and false negatives. Only a code review could solve such problems. Code reviews are expensive - not everyone in your organization would be capable of reviewing code with the eyes of a security expert.
To begin, with one can start with OWASP. Understanding the principles behind security is highly recommended before studying the OWASP Development Guide (3.0 is in draft; 2.0 can be considered stable). Finally, you can prepare to perform the first scan of your code base.
One of the first things that I have started to do with our internal application is use a tool such as Fortify that does a security analysis of your code base.
Otherwise, you might consider enlisting the services of a third-party company that specializes in security to have them test your application
Testing and static analysis is a very poor way to find security vulnerabilities, and is really a method of last resort if you haven't thought of security throughout the design and implementation process.
The problem is that you are now trying to enumerate all of the ways your application could fail, and deny those (by patching), rather than trying to specify what your application should do, and prevent everything that isn't that (by defensive programming). Since your application probably has infinite ways to go wrong and only a few things that it is meant to do, you should take an approach of 'deny by default' and allow only the good stuff.
Put it another way, it's easier and more effective to build in controls to prevent whole classes of typical vulnerabilities (for examples, see OWASP as mentioned in other answers) no matter how they may arise, than it is to go looking for which specific screwup some version of your code has. You should be trying to evidence the presence of good controls (which can be done), rather than the absence of bad stuff (which can't).
If you get somebody to review your design and security requirements (what exactly are you trying to protect against?), with full access to code and all details, that will be more valuable than some kind of black box test. Because if your design is wrong then it won't matter how well you implemented it.
We have used Telus to conduct Pen Testing for us a few times and have been impressed with the results.
May I recommend you contact Artec Group, Security Compass and Veracode and check out their offerings...