Where do you host your customers' ASP.NET sites? I am about to develop a few sites, and I am looking for a good place to host (cheap, fast, good bandwidth, good storage, updates, service packs, etc.)
I have also thought about earning revenue for the hosting/domain, even though I am not actually hosting it (kinda sounds bad when you put it out there). Basically, I would just handle the hosting/domain costs and bill the customer, with a bit of markup. They wont know anything about the host, unless they go digging. Does anyone else incorporate this into their business model? What are the pros/cons?
I like webhost4life. I've tried hosting customer stuff -- you can't charge them enough to deal with the pain. It's much better to give it up to somebody else to deal with the bandwidth and SLAs.
I've used Brinkster for several years & never had any unplanned outages or any real problems. Keep in mind that the sites I've worked on aren't high-volume sites (local restaurants, etc) so I haven't really pushed the envelope bandwidth-wise. Pricing is good & support has always helped me out when I needed it.
A note on marking up hosting...I'm a one-person shop & I tried this once (for a short time), and regretted it immediately. Every tiny email issue, Outlook configuration setting, etc. will result in a customer phone call to you. YMMV, but the markup was never profitable or worthwhile for me personally.
Peer1 is a bit expensive but offers an excellent support when something goes wrong (DNS, email, dabase, service pack...). They help you configure your server and take care of security aspects (amongmany others).
I also use ServerBeach (Peer1's little brother), its self-managed hosting which means you have to take care yourself of the security, the server's configuration, the service packs,... more flexible and less expensive. Support is also excellent.
Related
Can someone explain to me the real danger, XSS can do on internal sites using Windows Authentication. I know firewall can be break and hacker can access internal site but for now let's not focus on that. I just want to know what and internal employee(hacker) can do on a Windows Authentication environment using XSS.
Thanks,
Windows Authentication does not prevent XSS attacks or help detecting them, so it is irrelevant to the question.
An internal employee (hacker) can do all what any external hacker can do.... only about 10 times easier. Here is a quick comparison.
But practically speaking, because internal hackers can access information much easier and in more ways than external hackers, they usually use less sophisticated methods. They focus more on covering their tracks.
But then, who said that internal hackers have to do it from inside? Unlike the external hackers, they have the option to do it from both inside and outside. An employee can go to a coffee shop and perform an XSS attack (or any other attack) just like any external hacker. Their much deeper knowledge of the internal systems will make any attack much easier. Also IT employees can use the projects that are under their control to attack (XSS or otherwise) other projects that are not under their control.
The possibilities are limitless. It's nearly impossible to protect yourself from internal hackers. Your only hope is to find the tracks. The good news is that if you find the tracks, it is usually much easier to reach and punish internal hackers as long as they haven't fled the country.
That, however, doesn't mean that you don't need to bother. Your coworker can probably access your office, and even break the lock on your drawer and reach your wallet that you put there while you're having your lunch in the kitchen, but you still don't put your wallet on the desk in plain sight, do you? Well, at least you don't leave in on the table in the conference room. The better you protect your assets, the more sophisticated methods the hackers have to use, and the more likely they will leave tracks behind.
You can't ignore the security aspects for your internal Websites just because of the fact you believe that they aren't visibile to the outside world.
There were so far many cases of different companies ignoring the security of their internal apps just because they think it's safe. But...
you said your Website is behind a firewall. Are you 100% sure of the firewall configurations and that no one would be able to access it?
Are you 100% sure that your firewall is safe and no one could break it?
Are you 100% of your server configurations and this website is only accessible from your Internal network?
Are you 100% sure that there's no possible way to access this internal Website/Database/App or whatever using the public Interface that is visible to the outside world?
Also you mentioned that it's vulnerable for XSS. The fact that you ignored XSS could also mean that there are more dangerous vulnerabilities that you haven't found yet or maybe didn't bother to find because you believe that it's just an internal website.
Also as #Racil Hilan pointed out in his answer. An insider could also exploit such a vulnerability.
Even for an internal website, XSS prevention is important, because of what #shawkyz1 said, but, in my opinion, more so because of what #Racil-Hilan said.
The easiest way to gain access to a company's data is to apply for a job. If you're inside, you're trusted. Imagine that an employee is pissed off with the company, for example because he's heard he'll be laid off. He can cause tremendous damage with XSS, for example by injecting a script which also pipes all input to a location from which he can steal it as his leisure.
Or perhaps he doesn't even steal the data, but cause tremendous misinformation by slightly altering messages users try to send, for example by randomly incrementing numbers, or with a small change exchanging "do" and "do not".
Situation: The dba is an offsite contractor who keeps the entire DAL code checked out in TFS. It would be nice as the front end developer to be able to add columns, and tweak procs and whatnot, without having to rely on waiting for this dude to respond to your emails to do the work.
Question: What would be a recommended solution/process that would allow for more rapid/agile development, while maintaining data integrity as well as peace love and happiness among the team?
Im getting some good feedback on Programmers HERE
There is no general technical answer to your question (unless you can define a very limited kind of needed access, which can be supplied via an API he provides for you in the DAL, etc.).
Assuming you already tried to talk with him and probably even escalated the issue, there is probably a valid reason for limiting access (security, data model integrity, performance tuning, version control etc.).
Try to understand the reasoning behind his approach, and to better define your actual needs, it is possible that after that you can formulate an improvement to your architecture (such as the aforementioned API) or your development process. Most importantly, talk frankly about your concerns, communication can go a long way, as long as you are willing to understand the other side.
I've written a ASP.NET app that I hope to sell to businesses, I could host the trial but it's designed to connect to the customers data so customers will certainly want to install it to do a successful evaluation.
I've never produced anything commercial before so I'm looking for advice on how best to limit the trial, a 30 day trial seems most common, do you simply rely on the clock of the PC/Server they install it on? Any other suggestions welcome, please keep in mind this is ASP.NET app so will be installed on their web server.
Thanks
Craig
I would just do it via the PC's clock. At the end of the day, they could just change the clock and continue to use your software, though it's probably not going to work in practice (i.e. most software actually uses the date/time for other things as well and changing it going to screw that up).
Generally, you can usually trust business more than you trust the general public. The liability of a business is much higher than that of an individual, so if it came to it, you could potentially sue them for quite a bit. That alone means most businesses will purchase licenses for all of their software: a few hundred (or even thousand) dollars for a software license is much better than risk getting sued.
When they sign up for the demo, make sure you get all of their contact details and so on.
I would setup a web service on your server to authenticate the demo application. The web service should get called periodically and if it fails, then shut down the application. That way you have complete control over the trial (you can extend it or shut it down remotely).
You should give them some sort of key which they will place in your web.config that will identify them as a customer.
Make sure you take the usual precautions of encrypting / using hashes with both the key and the web service so it's not bypassed.
This sort of thing has been well covered on SO in the past.
You cannot make it unbreakable, but you can make it very difficult for the client to break your trial period.
One way to do it is to take the first run time and encrypt that info and store it either in your web.config or database. This has a weakness though: what do you do if the value is not present where you expect it to be?
Another option is to ping a webservice that you host. If the webservice says their trial is over then you can render the appropriate page to tell them that. This has the advantage that the webservice is beyond their control and cannot be messed with. It has the disadvantage that not every client will want to be allowing their web app to phone home, and there may be connectivity issues which would interfere with the functioning of your app.
So you might want to come up with a variety of options, and then implement a licencing module using the Provider pattern, so that you can swap in the licencing module most suitable for that client.
Put a counter in the web.config, of course give the counter a non-related name so the customer does not know what it is for. Every time they access the application you can increment the counter. Give them x number of log-in's.
If you want you can encrypt the counter if you do not want the customer to figure out that the counter is incrementing.
I'm working on a forum based website, the site also supports onsite messaging (ie. the users can send private messages to other users), what I'm trying to do is notify a member if they have new messages, for example by displaying the inbox link in bold and also the number of messgages, e.g. Inbox(3)
I'm a little confused how this can be implemented for a website running on a server farm, querying the database with every request seems like an overkill to me, so this is out of question, probably a shared cache should be used for this, I tend to think this a common feature for many sites including many of the large ones (running on server farms), I wonder how they implement this, any ideas are appreciated.
SO caches the questions, however every postback requeries your reputation. This can be seen by writing a couple of good answers quickly, then refreshing the front page.
The questions will only change every minute or so, but you can watch your rep go up each time.
Waleed, I recommend you read the articles on high scalability. They have specific case studies on the architectures of various mega scale web applications. (See the side bar on the right side of the main page.)
The general consensus these days is that RDBMs usage in this type of application is a bottle neck. It is also probably safe to say that most of the highly scalable web applications sacrifice consistency to achieve availability.
This series should be informative of various views on the topic. A word on scalability is highly cited.
In all this, keep in mind that these folks are dealing with Flickr, Amazon, Tweeter scale issues and architectures. The solutions are somewhat radical departures from the (previously accepted) norms and unless your forum application is the next Big Thing, you may wish to first test out the conventional approach to determine if it can handle the load or not.
This is a shameless information gathering exercise for my own book.
One of the talks I give in the community is an introduction to web site vulnerabilities. Usually during the talk I can see at least two members of the audience go very pale; and this is basic stuff, Cross Site Scripting, SQL Injection, Information Leakage, Cross Site Form Requests and so on.
So, if you can think back to being one, as a beginning web developer (be it ASP.NET or not) what do you feel would be useful information about web security and how to develop securely? I will already be covering the OWASP Top Ten
(And yes this means stackoverflow will be in the acknowledgements list if someone comes up with something I haven't thought of yet!)
It's all done now, and published, thank you all for your responses
First, I would point out the insecurities of the web in a way that makes them accesible to people for whom developing with security in mind may (unfortunately) be a new concept. For example, show them how to intercept an HTTP header and implement an XSS attack. The reason you want to show them the attacks is so they themselves have a better idea of what they're defending against. Talking about security beyond that is great, but without understanding the type of attack they're meant to thwart, it will be hard for them to accurately "test" their systems for security. Once they can test for security by trying to intercept messages, spoof headers, etc. then they at least know if whatever security they're trying to implement is working or not. You can teach them whatever methods you want for implementing that security with confidence, knowing if they get it wrong, they will actually know about it because it will fail the security tests you showed them to try.
Defensive programming as an archetypal topic which covers all the particular attacks, as most, if not all, of them are caused by not thinking defensively enough.
Make that subject the central column of the book . What would've served me well back then was knowing about techniques to never trust anything, not just one stop tips, like "do not allow SQL comments or special chars in your input".
Another interesting thing I'd love to have learned earlier is how to actually test for them.
I think all vulnerabilities are based off of programmers not thinking, either momentary lapses of judgement, or something they haven't thought of. One big vulnerability that was in an application that I was tasked to "fix up", was the fact that they had returned 0 (Zero) from the authentication method when the user that was logging in was an administrator. Because of the fact that the variable was initialized originally as 0, if any issues happened such as the database being down, which caused it to throw an exception. The variable would never be set to the proper "security code" and the user would then have admin access to the site. Absolutely horrible thought went into that process. So, that brings me to a major security concept; Never set the initial value of a variable representing a "security level" or anything of that sort, to something that represents total god control of the site. Better yet, use existing libraries out there that have gone through the fire of being used in massive amounts of production environments for a long period of time.
I would like to see how ASP.NET security is different from ASP Classic security.
Foxes
Good to hear that you will have the OWASP Top Ten. Why not also include coverage of the SANS/CWE Top 25 Programming mistakes.
How to make sure your security method is scalable with SQL Server. Especially how to avoid having SQL Server serialize requests from multiple users because they all connect with the same ID...
I always try to show the worst-case scenario on things that might go wrong. For instance on how a cross-site script injection can work as a black-box attack that even works on pages in the application that a hacker can’t access himself or how even an SQL injection can work as a black box and how a hacker can steal your sensitive business data, even when your website connects to your database with a normal non-privileged login account.