I really don’t know what to think about this one. Microsoft gives the following guidelines: hash and salt passwords, encrypting information. Now this topic is a bit broad, but let’s see it. If you don’t find my post detailed enough, feel free to refer this Patterns & practices article on MSDN.
Our first issue is the connection to a database. The main recommendation is: whenever it’s possible, use Windows Authentication. This has many benefits, including that you don’t need to store authentication information in your application, you don’t need to send this authentication info across the network, etc.
Continue reading “Ensure that sensitive information in applications is protected”
This post will be about the globalization and localization techniques ASP.NET provides us. There are two types of resources which you can use in an ASP.NET page: global, which means they are accessible from all pages, and local, for each given page. First let’s see how to use global resources.
To enable them, add a special folder named App_GlobalResources. In this folder, you can insert whatever resource you’d like to use. Let’s insert a .resx file, this will be the default culture you’d use. Let’s call it GlobResx.resx. Add a key-value pair, for example HeaderText = Hello World. Now on a random .aspx page, define a Label control, and set its text property to <%$ Resources: GlobResx, HeaderText %>. Now you are done, when you run your site, you’ll see Hello World as the label’s text.
Now let’s take a further step. Create a file named GlobResx.en.resx into the App_GlobalResources folder. Add the same HeaderText entry, but now use the value: Hello for the English-speaking World! If your browser is set up to use the English culture, you’d see your label shows the new text.
Continue reading “Plan Web Sites to Support Globalization”
Today I took my test and failed it with 560 points. The passing limit, as usual, was 700 points, so I wasn’t even close to it. However, now I know what to learn for, and my future posts will reflect this new found knowledge.
As I wrote yesterday (and I can confirm that based on today’s experiences) this exam isn’t the kind of “can you find the syntactic/logical error in the following four code samples”. It was about decisions in certain circumstances, so you should be able to select the best fitting solution for a given problem, from four (or more) possible answers.
I aced the Designing and Implementing Controls section, without any error, so I won’t focus on that. Instead, you’ll get more info on the topics of security, project types and navigation. Thanks to the second shot offer, I’m able to schedule this exam again for free, I guess I’ll do it in a week.
Anyone who read my most recent posts can think that they are just drafts. I think it’s true, because I don’t know what to prepare for, sometimes I wouldn’t like to review a topic, because I consider it too basic and sometimes I can’t even start to learn the exact same topic, because of the its complexity.
These things helped me make my decision: I’ll take this exam tomorrow. If I pass it, well, it’s good for me, I was prepared. If not, it’ll be good for you, because you get study material which was produced and reviewed by heart.
So I’ll post my experiences (and my result) tomorrow. The next exam I’m currently considering is the Windows Forms MCTS (70-505). But it’s possible that I’ll head for the 70-503, WCF exam, because I ordered the book a month ago, and I’d desperately like to read it.
In this section, I’d like to provide a guideline which helps you build a secure website in ASP.NET. The following list is from the Pro ASP.NET 3.5 in C# 2008 book, refer to it for further information.
Never trust user input: use strong validation method when you’re dealing with user input. Whenever possible, grant a white-list of values that are acceptable for the current input.
Never, never use string concatenation for creating SQL statements: really never do it. Use parameters instead, data source controls have natural support for them. In the lower level, every ADO.NET command class supports them either.
Never output user-entered data before validating and encoding it: this one’s barely need any explanation. If you do output that information, you expose your site to serious XSS attacks. To gain an idea about the seriousness of them, check out this video.
Never store sensitive or business logic data in hidden fields: your users aren’t dumb, they can open the source of your site, tamper with it, and send it back to you.
Never store sensitive data in the View State: View State is little more than another hidden field. If you assume that its encrypted, you are wrong. However, you can make sure that it’s the same what you’ve sent to the user by setting EnableViewStateMAC to true.
Enable SSL when using Forms Authentication: no comment, enable SSL if you can.
Protect your cookies: and don’t forget to set timeouts on them.
There may be several situations when your web pages need to handle long-running processes, for example, query information from a slow database, work with the file system, etc. In this case, you’d need to use asynchronous pages.
First you need to understand that asynchronous pages aren’t actually faster, than their synchronous counterparts. Using them won’t affect the speed of your site, just the scalability of it. The second thing to know is that you shouldn’t use the traditional multithreading ways when you are working with ASP.NET. ASP.NET serves incoming requests from its on thread pool; one thread is responsible for the whole lifetime of the request. When you use the Threading namespace, you are getting a thread from the very same thread pool ASP.NET itself uses. So you shouldn’t do it. Instead you should use asynchronous pages, which in fact gets their working threads from another thread pool, thus freeing up the ones in ASP.NET’s, which it can use to serve more requests.
Continue reading “Plan for Long-running processes by using Asynchronous Pages”
To maintain a consistent state for web server controls, ASP.NET provides you two powerful ways. As HTTP is stateless in its nature, we should use workarounds to ensure that our work and data are available between request. ASP.NET has two answers for this problem: View State and Control State.
Control’s View State is exactly the same hidden field on the generated HTML page as the page’s. In fact, Control State also uses the same hidden field.
What should you store in View State: as View State can be turned off for a page, you shouldn’t rely on it. The data or properties that are critical for your control (for example, the current index of a page) should be stored in Control State. Data related to the layout of a control should be stored in View State, but you should limit yourself. Pushing too much information into View State can result in slower postbacks, because View State information is send to the client, and then it’s sent back to the server. Sometimes it’s even encrypted, which makes the whole process more slower. Also, sensitive data shouldn’t be stored in View State, because it travels to the client’s computer, where it can be tampered with.
Continue reading “Manage States for Controls”