Scribd
Upload
31 views7 pages

Tips For Data Validation - ATI

Uploaded by

Walid Alsharafi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
31 views7 pages

Tips For Data Validation - ATI

Uploaded by

Walid Alsharafi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

(/besecure/en/?
noRedirect=1)

The 5 Golden Rules for


Tips from a Pentester on Data Validation

secure Data Processing

     

IMPORTANT FUNDAMENTAL CONCEPT FOR IT


SECURITY
Most security breaches can be prevented through proper data
validation.

One of the most fundamental concepts in IT security is data validation. It ensures


that data in a system can be processed correctly and protects the system from
“malicious” data. When used correctly, data validation can prevent a wide range of
attacks, including cross-site scripting (XSS), SQL injection, and buffer overflows.

The screenshot on the left shows how important data validation is.

You can see a fraction of the published CVEs (Common Vulnerabilities and
Exposures) from April 15, 2021. Within just four hours (12:15–16:15), seven
vulnerabilities were published that could have been prevented with sufficient data
validation.

For illustration purposes, the affected vulnerabilities are framed in red.


The five golden rules for secure data validation are as follows:

1. Server side Validation

Input validation must always take place on the server. Everything done on
the client side is essentially bypassable. For example, if JavaScript is used
for input validation, a simple script blocker is sufficient.

Attackers can also intercept and modify generated HTTP requests by using
a web interception proxy. This can also be used to bypass client-side
validation.

In principle, there is nothing to be said against additionally performing


data validation on the client side. This prevents the server from rejecting
many incorrectly formatted requests and the user from having to re-enter
all the data. However, this is a usability feature rather than a security
feature.

So, in overview:
Client side = Usability
Server side = Security
2. Never Trust Input

Keep this principle in your mind at all times. Even if the data appears to be
trustworthy, do not expect it to be properly formatted.

All input data, whether from an interface, configuration files, or the


database, must be validated.

Even if the data is generated by a self-written program, it is still


recommended that it be validated.

If one of the validation steps fails, the entire content should be rejected. We
do not recommend attempting to convert false input to real input because
the code that does so can be abused by attackers.

3. Using Whitelists

A common mistake is to use blacklists for data validation. A blacklist or


block list contains all characters (and strings) that are not allowed.

The problem with this is that a blacklist is almost never complete. Attackers
often find ways to circumvent a blacklist, for example by encoding
forbidden characters.

A whitelist, or allow list, contains all values that are allowed. All other values
are rejected by default. Such a system can hardly be circumvented.

For structured data, there is the possibility to create a whitelist regular


expression that specifies which characters may be used and what length
the input must have.
4. Validate Syntax and Semantics

Validation of data can be accomplished in two ways.

The purpose of syntactic data validation is to ensure that data has the
correct syntax, or structure. A social security number, for example, is always
a ten-digit number. Date fields and e-mail addresses always have a
consistent structure that can be verified. Regular expressions, for example,
are useful for this.

Semantic data validation involves assessing data values in their context. For
example, if an input field is a date of birth, it cannot be in the future.

To ensure the highest level of security, the syntax, and semantics must be
validated.

5. Output Encoding

The output encoding is an important player in data validation. Essentially,


not every “bad” character can be strictly forbidden as input.

If you want to avoid XSS but still allow symbols like, output encoding is
required.

The context always dictates how a character should be encoded. Angle


brackets, for example, can be encoded in an HTML context using HTML
entities (& lt ; gt ;). Characters that are not permitted in URLs must be
encoded in the HTTP context. Using URL encoding, the & symbol, for
example, can be represented as%26.

Other common encodings include ASCII and UNICODE for text and Base64
for binary data.

In conclusion:

If you follow these five golden rules, you can avoid many security gaps.
Some of them include:

• OWASP Top Ten A1: Injection
• OWASP Top Ten A7: Cross-Site Scripting

Furthermore, attacks are made more challenging in general, and the attack surface is
reduced.

Would you like to learn more about IT Security or increase your Company's
Security?
Our Advanced Threat Inspection solution can help you build effective protection for
your assets against cyberattacks. If you would like to learn more, please contact our
accomplished security experts.

cure/en/contact/)
Contact

It always starts with a


conversation
Let‘s talk about how we can improve your security posture –
today!​

cure/en/contact/)
Get in touch


Sitemap (/besecure/en/sitemap/)
Privacy Statement (https://bearingpoint.services/en/privacy-statement/)
Company information (https://bearingpoint.services/en/company-information/)

© 2024 BearingPoint (https://www.bearingpoint.com) All Rights Reserved

You might also like