Comments (19)
On topic (the issue) - new separate requirement.
I would suggest:
12.2.x Verify that the application enforces a maximum pixel size for uploaded images to prevent pixel flood attacks.
Maybe CWE 400?
L1
sidetopic - zip bomb, zip symlink, viruses and pixel flood - can be put to the same subcategory as separate requirements as those all are clearly malicious inputs
Opened #1769
from asvs.
Good one, I think there are other ways to achieve it also, like pbm images.
Now the good question is, should we have separate requirement for images to "check the dimensions to be in expected range" or use some other requirement to cover it.
We have close requirement for this.
# | Description | L1 | L2 | L3 | CWE |
---|---|---|---|---|---|
12.2.1 | [MODIFIED] Verify that when the application is accepting a file, it checks that the file extension of the file matches an expected file extension and that it validates that the contents of the file match the type represented by that extension, including but not limited to checking the initial "magic bytes". | ✓ | ✓ | 434 |
As separate requirement it should belong to 12.1, as there are some archive content validation requirements, so validating something image specific fits there as well.
# | Description | L1 | L2 | L3 | CWE |
---|---|---|---|---|---|
12.1.2 | Verify that the application checks compressed files (e.g. zip, gz, docx, odt) against maximum allowed uncompressed size and against maximum number of files before uncompressing the file. | ✓ | ✓ | 409 | |
12.1.4 | [ADDED] Verify that the application does not allow uploading compressed files containing symlinks unless this is specifically required (in which case it will be necessary to enforce an allow list of the files that can be symlinked to). | ✓ | ✓ | 61 |
from asvs.
I agree this should be in a general file checking requirement. @ImanSharaf can you suggest where to add it?
from asvs.
Verify that when the application is accepting a file, it checks that the file extension of the file matches an expected file extension and that it validates that the contents of the file match the type represented by that extension, including but not limited to checking the initial "magic bytes".
To point out more clearly: ... including but not limited to checking the initial "magic bytes".
So, if I find this vulnerability, requirement 12.2.1 is something to use for reporting. The question is - should be put some special hilight on the attack vector in the 12.2.1 or in some new separate requirement.
from asvs.
So I don't think 12.2.1 applies in this case because @ImanSharaf is talking about a situation where the filetype is as expected but it effectively contains a denial of service payload.
As such, @ImanSharaf it would be good to get your perspective on the specific requirement to be added and where?
from asvs.
If it will be separate requirement, we can look current 12.1.2 as a direction.
# | Description | L1 | L2 | L3 | CWE |
---|---|---|---|---|---|
12.1.2 | Verify that the application checks compressed files (e.g. zip, gz, docx, odt) against maximum allowed uncompressed size and against maximum number of files before uncompressing the file. | ✓ | ✓ | 409 |
One more question to answer - should we watch as malicious content in general and handle them like viruses, or should we have requirement only to protect an application - if you going to create thumbnails and load image to the memory based on dimensions described by user, then validate the maximum allowed dimensions.
from asvs.
If it will be separate requirement, we can look current 12.1.2 as a direction.
I think there is a theoretical risk in trying to cover all the possible bad things that can happen in an uploaded file, it may be there is no limit to the possibilities.
On the otherhand, in the same way as we specifically talk about zipped files, images are also highly common with some common risks.
As such, I think we should have a separate requirement, similar to 12.1.2 about this issue.
One more question to answer - should we watch as malicious content in general and handle them like viruses, or should we have requirement only to protect an application - if you going to create thumbnails and load image to the memory based on dimensions described by user, then validate the maximum allowed dimensions.
We already have 12.4.2 to cover this:
# | Description | L1 | L2 | L3 | CWE |
---|---|---|---|---|---|
12.4.2 | Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload and serving of known malicious content. | ✓ | ✓ | ✓ | 509 |
from asvs.
Yes I know we have separate requirement for viruses, my question was - should we watch the pixel flooded image as virus as well? It's clearly malicious content.
And the zip bomb (12.1.2)? And symlinked zip (12.1.4)? It makes sense to put them to one subcategory?
from asvs.
Same category, maybe. Some requirement, no
from asvs.
Clarification:
- On topic (the issue) - new separate requirement.
- sidetopic - zip bomb, zip symlink, viruses and pixel flood - can be put to the same subcategory as separate requirements as those all are clearly malicious inputs
from asvs.
12.2.x Verify that the application enforces a maximum pixel size for uploaded images to prevent pixel flood attacks.
What means "enforces" in this context?
from asvs.
enforces = uses input validation on images with a pixel size larger than the maximum allowed to either reject them or reduce the pixel size down to the maximum
from asvs.
or reduce the pixel size down to the maximum
but pixel flood attack is addressing exactly this functionality, no?
Maybe we should watch this potential pixel flood image as zip bomb or virus content - clearly malicious, do not proceed?
from asvs.
An antivirus doesn't detect that as a malicious file!
from asvs.
On topic (the issue) - new separate requirement.
I would suggest:
12.2.x Verify that the application enforces a maximum pixel size for uploaded images to prevent pixel flood attacks.
Maybe CWE 400?
L1
sidetopic - zip bomb, zip symlink, viruses and pixel flood - can be put to the same subcategory as separate requirements as those all are clearly malicious inputs
Opened #1769
I am good with this.
from asvs.
An antivirus doesn't detect that as a malicious file!
I wrote: Maybe we should watch ...
from asvs.
On topic (the issue) - new separate requirement.
I would suggest:
12.2.x Verify that the application enforces a maximum pixel size for uploaded images to prevent pixel flood attacks.
Maybe CWE 400?
L1
sidetopic - zip bomb, zip symlink, viruses and pixel flood - can be put to the same subcategory as separate requirements as those all are clearly malicious inputs
Opened #1769
Following discussion with @elarlang,
12.2.x Verify that the application blocks uploaded images with a pixel size larger than the maximum allowed, to prevent pixel flood attacks.
from asvs.
@ImanSharaf are you ok with that as well
from asvs.
So, I took:
- requirement text and category/section from here: #1740 (comment)
- CWE from here: #1740 (comment)
- Level 1 - it is relatively easy to implement, just check the image pixel size first
and created PR: #1803
If @ImanSharaf has some improvement ideas, we can reopen the issue.
Category and section may be changed in the future - #1769
from asvs.
Related Issues (20)
- Requesting Clarifying Definition in the Business Logic Section Header
- Something amiss in requirement description for v5.0-50.5.3 HOT 4
- lowercase vs uppercase grammar (original: 6.2.1 causes capitalization inconsistency) HOT 10
- 5.1.1 - terminology, GET and POST... HOT 14
- clarifying 5.1.3 HOT 9
- Should easily visible logout functionality be a requirement or a recomendation HOT 15
- Tracking supporters HOT 6
- V9 rework - 9.2.5 has insufficient value HOT 5
- 2.10.5 (v4.0.3-9.2.3) - belongs in authentication (needs improvement and scope check) HOT 15
- 7.2.3 (v4.0.3-7.1.3) - wording improvement HOT 4
- 7.2.4 (v4.0.3-9.2.5) - improve the wording to cover all connection errors and failed certificate checks HOT 7
- move section V5.5 (and V5.4) to V10 HOT 18
- Ismael HOT 1
- Finalize web socket requirements HOT 12
- Proposal to remove serverless references HOT 6
- oauth related discussions HOT 2
- cleanup V3.5 Token-based Session Management HOT 3
- V8.3 security and policy HOT 11
- encoded sensitive data (such as JWT) should not be logged HOT 5
- proposal: move 1.14.6 to V50 (Web Frontend Security) HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from asvs.