I am planning to get my website development outsourced to a third party developer. Need your help in deciding on how/ what technology to be used to make it very secure. Since I am not a techie I need the website developed in a way, so that it is easy for me to maintain it and modify content easily if required.
The main purpose of the website is to provide company information about services offered and then also to exchange documents and other file using FTP server. Will be sending out surevey and newletters sometime
Looking for your advice to guide me to the right direction
As I already said on another answer, security is not a product, it's a process.
There isn't a 'secure' software or language. What makes your website/application secure is how it is developed and how the website is maintained.
There is no ready-made solution that, one time or another, won't be hacked.
If the people you are outsourcing to don't understand this, outsource to someone else.
Making your web server "hardened" against attack is best left to the expert sys-admins at Server Fault. However regardless of what technology you use, there is one HUGE thing an end user can do to protect her/his online assets:
USE STRONG PASSWORDS
You can make a site secure using any technology/language/framework.
It's the code quality that makes a site insecure, not the technology/language/framework.
There is no single "correct" language to use -- it's possible to write an insecure website in any language.
The key is hiring staff that have the skill and experience in developing secure web solutions, and also making sure that the system is tested often by external specialists
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)
This question might sound trivial, but even after reading a number of tutorials, I still don't get how the REST security should be implemented.
I have a webpage and soon-to-be-ready mobile app. Both of them will be using the REST API (written in node.js), and the question is - how can I prevent users from modyfing those requests? It's very easy to see the network traffic in the browser, and all the GET/POST requests that are made to the server. It also seems very easy to copy such a request, modify its parameters and/or payload and send it to the server.
How do I make sure that's my webpage or the app who made the request, and not someone else?
Sisyphus is absolutely correct: your focus should be on securing the channel (TLS, SSH, etc) and authentication (e.g. OAuth2).
You should absolutely familiarize yourself with the Open Web Application Security Project (OWASP). In particular, start with:
OWASP Top 10 Cheat Sheet
OWASP REST Security Cheat Sheet
Here is an excellent "hands on" tutorial that gives you a great overview of all the different pieces you need to worry about:
Authenticate a Node.js API with JSON Web Tokens
Once you've gone through the tutorial and scanned the OWASP cheat sheets, you'll have a much better idea of what kinds of things you need to worry about, what options/technologies are available to mitigate those risks, and what might work best for your particular scenario.
Good luck!
Typically, security these days uses a combination of Transport Layer Security and OAuth2. OAuth2 provides authentication and authorisation, ensuring appropriate access to resources, with TLS both securing data over the network and preventing the kind of replay attacks which you're concerned about. Neither are really specific to Restful APIs and you can find them being used in non-Rest contexts also.
I am currently working on security for a website (JSP) that contains 2 pages: a login and a data page. Once a user logs in, he is able to SELECT data from a specific table with read only access.
After browsing security risks online, I have wrote down a general list of what I might have to defend against
Injections
XSS
Auth / Session hijacking
CSRF
Direct Object Ref
Currently, I am reading about how to defend these attacks and what I should include in my code. However, I won't really know if my code actually works unless I test these attacks out for myself (and even then, there still might be other attacks that work). Right now, I just want some security, and thus I need to know how to produce these attacks so I can try them on my site.
Injections were simple as all I had to do what type '1'='1 in my code to reveal that it was flawed. Then I used prepared statements and SQL injections didn't work anymore.
How can I produce the rest of these attacks to see if my security atleast works against basic attacks?
(Also, is there perhaps some safe site or tool I can use to test out my vulnerabilities?)
I assume from your list that you're looking at the Open Web Application Security Project Top Ten. Good!
Really, the best advice I can give is to read through the OWASP site. A good first step would be to go through the individual links on that page (e.g. Broken Authentication and Session Management) and check the "Am I vulnerable?" section. Here are some further hints:
XSS
The XSS Cheat Sheet can be pretty helpful here. More examples than you can shake a stick at, ready to paste into your site.
CSRF
OWASP's wiki has a CSRF Testing Guide full of great links and suggestions.
Auth/Session hijacking
Well, are you using HTTPS? See this answer for more.
More resources
If you want to Go Deeper and do some real testing, here are some things you can do:
Read the Web Application Hacker's Handbook.
Try out some of the examples on http://hackthissite.org and the Google Gruyere project and see if you can break into them.
Download Kali Linux and learn to use some of the tools that come with it.
Go to a security conference or minicon near you and connect with other infosec people. Maybe I'll see you there :)
I need a utility to be given to my customer having site name A.com where he can decry-pt messages passed from my own site (i.e. B.com), which is build in Java technology.
Utility should be independent of technologies used by customer web site for their development.
Question: What technology should be used for developing such a Utility ?
Note: I have read that JavaScript is not good for cryptography.
The best option would be to use an existing, tried-and-tested protocol. TLS is a good choice for securing communication between two parties.
If, for some reason, you cannot use an existing protocol, you'll have to design your own, and describe it in such detail that others can implement it on their platforms. But this is very far from ideal for several reasons. Designing cryptographic protocols is hard, and even experts regularly get it wrong. Implementing cryptographic protocols is hard too, and experts often also get this wrong. There is simply no way a non-cryptographer could design or implement a secure protocol.
Web applications on uncompromised computers are vulnerable to XSS,CRSF,sql injection attacks and cookie stealing in unsecure wifi environments.
To prevent those security issues there are the folowing remedies
sql injection: a good datamapper(like linq-to-sql) does not have the risk of sql injection (am i naïeve to believe this?)
CSRF: Every form-post is verified with the <%:Html.AntiForgeryToken() %> (this is a token in a asp.net mvc environment that is stored in a cookie and verified on the server)
XSS: every form that is allowed to post html is converted, only bb code is allowed, the rest is encoded . All possible save actions are done with a post event so rogue img tags should have no effect
cookie stealing: https
Am i now invulnerable to web-based hacking attempts(when implemented correctly)? Or am i missing some other security issues in web-development?(except for possible holes in the OS platform or other software)
The easy answer is "No you're not invulnerable - nobody is!"
This is a good start, but there are a few other things you could do. The main one you haven't mentioned is validation of untrusted data against a white-list and this is important as it spans multiple exploits such as both SQLi and XSS. Take a look at OWASP Top 10 for .NET developers part 1: Injection and in particular, the section about "All input must be validated against a whitelist of acceptable value ranges".
Next up, you should apply the principle of least privilege to the accounts connecting to your SQL Server. See the heading under this name in the previous link.
Given you're working with ASP.NET, make sure Request Validation remains on and if you absolutely, positively need to disable it, just do it at a page level. More on this in Request Validation, DotNetNuke and design utopia.
For your output encoding, the main thing is to ensure that you're encoding for the right context. HTML encoding != JavaScript encoding != CSS encoding. More on this in OWASP Top 10 for .NET developers part 2: Cross-Site Scripting (XSS).
For the cookies, make them HTTP only and if possible, only allow them to be served securely (if you're happy to only run over HTTPS). Try putting your web.config through the web.config security analyser which will help point you in the right direction.
Another CSRF defense - albeit one with a usability impact - is CAPTCHA. Obviously you want to use this sparingly but if you've got any really critical functions you want to protect, this puts a pretty swift stop to it. More in OWASP Top 10 for .NET developers part 5: Cross-Site Request Forgery (CSRF).
Other than that, it sounds like you're aware of many of the important principles. It won't make you invulnerable, but it's a good start.
Am I now invulnerable to web-based hacking attempts?
Because, no matter how good you are, everyone makes mistakes, the answer is no. You almost certainly forgot to sanitize some input, or use some anti-forgery token. If you haven't now, you or another developer will as your application grows larger.
This is one of the reason we use frameworks - MVC, for example, will automatically generate anti-CSRF tokens, while LINQ-to-SQL (as you mentioned) will sanitize input for the database. So, if you are not already using a framework which makes anti-XSS and anti-CSRF measures the default, you should begin now.
Of course, these will protect you against these specific threats, but it's never possible to be secure against all threats. For instance, if you have an insecure SQL-connection password, it's possible that someone will brute-force your DB password and gain access. If you don't keep your versions of .Net/SQL-Server/everything up to date, you could be the victim of online worm (and even if you do, it's still possible to be zero-dayed).
There are even problems you can't solve in software: A script kiddie could DDOS your site. Your server-company could go bankrupt. A shady competitor could simply take a hedge-clippers to your internet line. Your warehouse could burn down. A developer could sell the source-code to a company in Russia.
The point is, again, you can't ever be secure against everything - you can only be secure against specific threats.
This is the definitive guide to web attacks. Also, I would recommend you use Metasploit against your web app.
It definitely is not enough! There are several other security issues you have to keep in mind when developing a web-app.
To get an overview you can use the OWASP Top-Ten
I think this is an very interesting post to read when thinking about web-security: What should a developer know before building a public web site?
There is a section about security that contains good links for most of the threats you are facing when developing web-apps.
The most important thing to keep in mind when thinking about security is:
Never trust user input!
[I am answering to this "old" question because I think it is always an actual topic.]
About what you didn't mention:
You missed a dangerous attack in MVC frameworks: Over Posting Attack
You also missed the most annoying threats: Denial of Service
You also should pay enough attention to file uploads (if any...) and many more...
About what you mentioned:
XSS is really really really waster and more annoying to mitigate. There are several types of encoding including Html Encoding, Javascript Encoding, CSS Encoding, Html Attribute Encoding, Url Encoding, ...
Each of them should be performed to the proper content, in the proper place - i.e. Just doing Html Encoding the content is not enough in all situations.
And the most annoying about XSS, is that there are some situations that you should perform Combinational Encoding(i.e. first JavascriptEncode and then HtmlEncode...!!!)
Take a look at the following link to become more familiar with a nightmare called XSS...!!!
XSS Filter Evasion Cheat Sheet - OWASP