PM535701 (Community Member) asked a question.
Use of a Broken or Risky Cryptographic Algorithm (CWE ID 327)(30 flaws)
how to fix this issue in dot net core 2.0 application?
how to fix this issue in dot net core 2.0 application?
I am getting this issue on microsoft.identitymodel.tokens.dll and microsoft.codeanalysis.dll. I tried with commenting the code where we are using those DLL's in my application and that still showing the issues.
I ran the scan with only those two DLL's (with current and latest versions) and I am able to see all the issues but there is a change in flaw ids. (I don't know how flaw ids got changed)
I am unable to find them where exactly was the issue whether it is from my application or Microsoft DLL's.
Please find the below screenshot.
.png){kind=logo}
Can someone please help me to mitigate the above issue.
I tried with empty dot net core 2.0-Angular project without making code changes.
But still i can able to see the flaws. Is it challenge to Microsoft? or shall i have to make any configuration changes to mitigate the flaws?
Hi @PM535701 (Community Member) - I am so sorry for the wait. Our Application Security Consultant team is catching up with all the client works after the company kick-off meeting. I will be sure they get to your question this week. Thank you again for your patience.
Hi @PM535701 (Community Member) ,
In the Veracode Platform please click on the "Static Scan" link then go to "Review Modules" for your static scan and ensure that you have not selected the Microsoft dlls as entry points.
We do not recommend selecting these DLLs as entry points for Veracode Static Analysis. Please ensure that you only select as a module with an entry point of that part of your application that is exposed to a user, typically for .NET scans this would be .exe files, App_....dll or .Views.dll.
If you have any remaining questions please schedule a consultation from the Veracode Platform or if you do not have this capability please contact your security team.
Thank you,
Boy Baukema
Hi @Boy, Security Consultant (Veracode),
Thanks for the update. Can we use this recommendation as an official resolution and as a way to mitigate the report?
Hi @PM535701 (Community Member) ,
I'm afraid I don't understand the question. Please follow the above guidance with regards to module selection to ensure you are not selecting third party modules as entry points.
If you have any questions with regards to the scope or configuration of a scan please contact your security team and/or schedule a consultation in the Veracode Platform: https://help.veracode.com/r/t_schedule_consultation .
Does this answer your question?
Thank you,
Boy Baukema
Hi @Boy, Security Consultant (Veracode),
In the line of the DLLs mentioned in the original post, we have the following issues as well with third party DLLs -
Do you recommend the same approach to mitigate these all?
Hi @BC108097 (Community Member) ,
Please follow the above guidance with regards to module selection to ensure you are not selecting these third party modules as entry points.
If you have any questions with regards to the scope or configuration of a scan please contact your security team and/or schedule a consultation in the Veracode Platform: https://help.veracode.com/r/t_schedule_consultation .
Does this answer your question?
Thank you,
Boy Baukema
@Boy, Security Consultant (Veracode) It does, upto certain extent.
To understand the point better, you're asking to upload only the custom developed DLLs and not the third party dependent ones. Is there a chance that the third party DLLs shall still be referred by Veracode during the static run if the custom DLLs have internal references to them?
For example, paraphrasing DLLs from the queries in this thread,
Say I have uploaded ONLY custom abc.def.xyz.dll and none other third party DLLs for a fresh scan. Now, abc.def.xyz.dll has internal references to microsoft.*. dll as a form of code references and bindings. Can you please confirm if the static scan process is going to consider the microsoft.*.dlls?
Hi @BC108097 (Community Member) ,
Thank you for checking with me. I'm sorry I may have been unclear.
Please upload all files relevant to your application for Veracode Static Analysis, including third party files.
Do also review the Packaging Guide for the technologies that comprise your application: https://help.veracode.com/r/compilation_packaging .
In general a good rule of thumb is "Give to Veracode Static Analysis those parts of the application you would need to give to a sysadmin for a brand new production machine, only make sure you also include debugging symbols".
So for a .NET application you would not need to provide us with IIS or the .NET framework, just the files of your application, typically .exe and .dll files and perhaps also .js files. Many of these (most likely most of these) will be third party.
Another good rule of thumb is "When in doubt, upload it". Veracode Static Analysis is built to remove files it doesn't support or can't scan (like .jpg, .log, .xml, etc).
However after you've uploaded to the static scan Veracode Static Analysis will initiate the 'pre-scan' this will investigate the upload and discover one or more 'scannable modules'. A 'scannable module' is a grouping of related files in a given technology sent for analysis as one unit of work.
For several technologies (like .NET or Java) we may need not be sure what parts of your application is exposed to the outside world (what is your 'entry point') so we may provide you with multiple modules, several overlapping with different entry points.
We use this to determine whether functionality is used or not.
So if you select for example 'diagnostics.dll' as an entry point our analysis will treat every public method of that DLL as it if was directly exposed to user. This is likely incorrect and may give you flaws that don't relate to the actual use of your application.
So we recommend that you review your modules upon initial scan, or after the scan, and either select all modules with a first party entry point (for a more in-depth analysis) or all modules with an entry point that is externally facing (for less flaws in functionality you may not be currently using).
If you have any questions on this please feel free to schedule a Consultation, more information on this process here: https://help.veracode.com/r/t_schedule_consultation .
If you're using an integration like Jenkins of VSTS this may mean performing the initial scan, then going to the Veracode Platform and correcting the modules through "Review Modules" and starting a rescan.
Please let me know if you have any remaining questions or concerns.
Thank you,
Boy Baukema
Hi @Boy, Security Consultant (Veracode),
Thanks for your detailed response above. You mentioned "we recommend that you review your modules upon initial scan, or after the scan, and either select all modules with a first party entry point (for a more in-depth analysis) or all modules with an entry point that is externally facing(for less flaws in functionality you may not be currently using)".
In case we want to proceed with dynamic scan, can you please help us to understand if there's a similar process to exclude the third party DLLs?
Thanks