Static Application Security Testing(SAST) findings on SAS Reports.

[saslovethemost]

Hi,

Question on SAST findings. Please find the attached SAST findings as a word document. Want to know how is this be a threat like mentioned in the SAST findings, if it is a threat then how to handle the code. Please let me know. We use SAS grid servers and SAS9.4 ver. 

I have sql code like below (77 line from the attached word document) in a SAS report program

CREATE TABLE TOS004 AS 
SELECT * FROM CONNECTION TO MDW (
SELECT A.NBR_SVCR nbr_svcr
xxx,
xxx,
xxx
FROM udbadm.TMGT_ALL A
,udbadm.TMGT_PE_CVRG C
WHERE A.NBR_SVCR = %unquote(%str(%'&nbr_svcr%'))
ORDER BY A.NBR_SVCR);

255 line:

%macro htmlpt;
data _null_;
file _webout;
%let RV=%sysfunc(appsrv_header(content-type, application/msword));
*put 'Content-type: application/msword';
*put 'Pragma: no-cache';
*put 'Cache-control: max-age=0';
*put;
run;

*ods listing close;

options orientation=landscape;  *papersize=legal;
ods rtf file= _webout style=fax;

proc print data=tos005 split='*' noobs label;
     var  nbr_tmgt
          nbr_svcr
          name_ce
          dt_actl
          dt_plnd
          cd_rcvry;
     format dt_actl dt_plnd mmddyy10.;
     label nbr_mrtg = 'xxxxxxxxxxxx'
		   nbr_svcr = 'Servicer*Number'
           name_ce = 'XXXXXXXXXXXXX'
     	   dt_actl = 'Actual Coverage*Termination Date'
     	   dt_plnd = 'Planned Coverage*Termination Date'
	 	   cd_rcvry = 'Recovery Source';
     title1 "XXXXXXXXXXXXXXXXXXX";
     title2 "Credit Enhancements for Seller &nbr_slr";
run;

*proc print data=tos005;
*run;

ods rtf close;
%mend htmlpt;

Here is the code to print on the HTML webpage.

%macro print;
%if &anyobs=yes %then %do;
  %if &excel=NO %then
    %do;
    %htmlpt;
    %end;
  %if &excel=YES %then
    %do;
    %xlprint;
    %end;
%end;
%mend print;

Thanks and really appreciate your time.

Neal.

[SASKiwi]

I suggest you would be better off tracking this to SAS Tech Support as there are unlikely to be too many community users familiar with SAST.

Having said that I suspect it is the open code strings like &nbr_svcr that the report is referring to. If these are not sensitive data then the fact they are not encoded should not be that important. Also this report should be considered in the context of your SAS security architecture. For example if all of your SAS network traffic is already encrypted, and you are using HTTPS connections on all of your web servers, along with limiting access to SAS using AD group permissions as well as SAS metadata, then the fact that you are passing around un-encoded strings doesn't appear to be that important in my opinion.

[saslovethemost]

Right I am referring &nbr_svcr in both the places (one in SQL and other one is in title), we are using HTTPS connections and this is intranet to the comapany, all the reports are on the grid server. Following is the sample web url.

https://sasgrid.xxxx.com/SASStoredProcess/Utilities/ReportPageBuilder

As you said we have a group which uses AD (auth domain) to connect to the db server and run the SQL query.

I am not sure how is this a threat, thanks for the quick reply.

[SASKiwi]

OK, the fact that you are running purely on an intranet, and are using HTTPS (and probably firewalls around servers) means that the chances of external hackers causing havoc with un-encoded strings appears to be virtually nil in my opinion. The chances of a rogue employee doing something would be significantly higher, but then there is a much greater likelihood of being caught too.

IMO if your SAS security architecture is pretty sound then I wouldn't be worrying about these un-encoded strings. I'd be interested to see other users' opinions as well.

[saslovethemost]

The security analyst suggested to use white-list input validation on symget('nbr_slr) to make sure only alphanumeric characters is allowed.