You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have identified a path traversal vulnerability in the SurveyKing application, which affects two specific urls: "public/upload" and "file/create". This vulnerability allows an attacker to access files outside of the intended directory and potentially retrieve sensitive information from the server.
The vulnerability arises from the lack of proper input filtering on the content of uploadFile.getOriginalFilename().
Recommendation: Add a validation in the FileServiceImpl class to check if the file name returned by uploadFile.getOriginalFilename() contains "..". If it does, reject the file upload.
For the version v0.2.0, the position is in class "LocalStorageService". In the 'uploadFile' method, the content obtained from 'getOriginalFilename' should be filtered to check if it contains ".." before constructing the file path.
There are two other issues here.
2. XSS
The "/file/create" interface is used for uploading background images, but there is no filtering for the uploaded file types. Therefore, I suggest adding a check for the file type in the FileApi.upload method. The uploaded files will be displayed in an tag. Not checking the file type can potentially lead to XSS injection vulnerabilities.
Version v0.2.0 has the same problem. Accessing the upload endpoint via "${api.prefix}/files" provides an interface for uploading images, but there is no restriction to upload only image-format files. Additionally, when constructing HTML using "listImages" and similar methods to fetch images, there is no filtering applied.
3. DDoS
In the "FileServiceImpl.upload" method, if it is determined that the file is an image file, thumbnailator is used to generate a thumbnail. There is no restriction on the size of the uploaded file here. If the image is complex to load (such as progressive JPEG) or too large, it could consume a significant amount of server resources, leading to a potential DDoS attack.
For the version v0.2.0, the position is in class "LocalStorageService".
The text was updated successfully, but these errors were encountered:
1. PathTravel
I have identified a path traversal vulnerability in the SurveyKing application, which affects two specific urls: "public/upload" and "file/create". This vulnerability allows an attacker to access files outside of the intended directory and potentially retrieve sensitive information from the server.
The vulnerability arises from the lack of proper input filtering on the content of uploadFile.getOriginalFilename().
Recommendation: Add a validation in the FileServiceImpl class to check if the file name returned by uploadFile.getOriginalFilename() contains "..". If it does, reject the file upload.
For the version v0.2.0, the position is in class "LocalStorageService". In the 'uploadFile' method, the content obtained from 'getOriginalFilename' should be filtered to check if it contains ".." before constructing the file path.
There are two other issues here.
2. XSS
The "/file/create" interface is used for uploading background images, but there is no filtering for the uploaded file types. Therefore, I suggest adding a check for the file type in the
FileApi.upload
method. The uploaded files will be displayed in an tag. Not checking the file type can potentially lead to XSS injection vulnerabilities.Version v0.2.0 has the same problem. Accessing the upload endpoint via "${api.prefix}/files" provides an interface for uploading images, but there is no restriction to upload only image-format files. Additionally, when constructing HTML using "listImages" and similar methods to fetch images, there is no filtering applied.
3. DDoS
In the "FileServiceImpl.upload" method, if it is determined that the file is an image file, thumbnailator is used to generate a thumbnail. There is no restriction on the size of the uploaded file here. If the image is complex to load (such as progressive JPEG) or too large, it could consume a significant amount of server resources, leading to a potential DDoS attack.
For the version v0.2.0, the position is in class "LocalStorageService".
The text was updated successfully, but these errors were encountered: