Four practices on improving you custom web and SharePoint application security
by Yaroslav Pentsarskyy
Now that SharePoint has become a platform for building variety of solutions in many organizations, more of often than not we need to make customizations and add various custom features.
There are multiple ways to implement our customizations and depending on the approach selected we have to be aware of development practices that make our solutions more secure. In this article we will take a look at some of the most common mistakes that can lead to future application vulnerabilities.
Whether you’re creating applications for Internet facing sites or solution used internally, you can’t assume about user’s technical skills when it comes to security best practices.
Here are some common design and development errors that in real life have lead to security breach of various applications.
First one on the list: allowing users to upload files to application root directory.
This one is more applicable to web applications in general rather than SharePoint and I will explain why. It’s quite common for your solution to let user upload files to the server for further processing.
Whether those are images or maybe excel sheet your application needs to perform work on, there is a potential threat associated with this scenario. In one of the cases I have been involved with, an application was accepting a file from an administrative user. A file was an image that was associated to a business object for further display within a web application.
One day, of course, we found out that our system was breached. After a bit of investigation, we realized that someone has uploaded an aspx file instead of a planned image file and executed that script on the server. In this scenario, a file was placed into a directory within web application folder and due to a default security setting the content was executable.
Lessons learned from here:
1. Don’t upload files uploaded by users to a disk unless those files have to be permanently stored, if you need to perform temporary calculation – use object in memory instead.
2. If you need to save uploaded files to a disk – store them in the directory outside of your web application or disable script execution on the directory if it must be in your web application folder.
Next scenario: relying on JavaScript input validation.
Now that we’re all entering the world of Web 2.0 and nice dynamic web functionality is offered by a variety of JavaScript frameworks – don’t forget to do a server validation. When developing your application you may forget that by relying on validation logic using JavaScript is only good for folks that have JavaScript enabled in their browser. If a user knowingly or unknowingly disables the execution of JavaScript in their browser – they are in control of what’s happening on the page.
So, if you’re relying on that phone number or valid email address to go into the database in the correct format – there is a surprise for you in store when you pull those database reports.
Not too long ago, a coworker of mine found “a way” to bypass annoying SharePoint out of the box limitation by disabling JavaScript in the browser. In this scenario it was an innocent change but it rings a bell of caution. My suggestion is to always run server side validation for at least critical parts of the application to ensure your system is not manipulated. The same approach applies to dynamic page manipulation. Just because you set parts of the screen to be hidden based on users input using JavaScript – doesn’t mean it will remain hidden if this functionality was executed with a browser with turned off JavaScript.
Next threat on the list: Storing hidden values on your page.
I remember since I started working with web applications years ago, I was always tempted to go behind the page source and see how things worked. Well, these days developers seem to forget that page source records values of almost anything on the page.
I have recently seen a developer creating a wizard-like set of pages that relied on customer ID populated of the first page and retained as a hidden value throughout the rest of the pages.
This essentially means that as a “curious” customer, I can save all of the pages representing web wizard, overwrite the hidden value just by opening a page source and submit my information with various parameters in the database. The best practice in this scenario is to rely as little as possible on the client application, in our case – browser, to remember the information – save it in session or encrypted view state.
Last in this article but far not last in general: Elevating SharePoint privileges.
We all know that in SharePoint we can elevate code execution permissions to run under highest permissions available – a system account.
Keep in mind that this not only makes your code security vulnerable but also any action that runs under a System Account is recorded as being ran under a “System Account”. This mean that if a list item is created in your SharePoint list – it will have it’s “Created By” field populated as “System Account”.
Once, I witnessed a situation where developer decided to elevate entire chunk of code due to annoying exception he didn’t bother to “decrypt”. The security exception disappeared but in this case all of the records in SharePoint records centre were recorded under a system identify.
This became apparent when record managers realized they lost a month worth of valuable metadata. Suggestion here: with the great power of a System Account comes a lot of responsibility OR elevate responsibly.
This article is definitely not exhaustive but gives few good ideas.
Essentially, as a developer you have to keep in mind both functionality of your applications as well as potential security risks.
Please be sure to comment or vote if you found this content useful.
Yaroslav Pentsarskyy
Blog:
www.sharemuch.com
