BPM, Workflow, and Case

Mohammed, 

the steps appear to be the same as in your post at https://community.ibm.com/community/user/discussion/missing-access-control#bmd2c22511-3831-4719-b950-019960970819

While the other post is titled "missing access control", this one talks about tampering traffic in transit. I strongly recommend, you connect with your penetration testing team and find out, what their exact concern is: missing access control or tampering with traffic.

Regarding missing access control, you must ensure that your server side code only accepts parameter values that the current user is entitled to send. You can use BAW's JavaScript APIs to determine the current user name, group memberships and even team memberships. You can call out to backend systems and look up database tables to implement your custom implementation logic. The product as such cannot have any built-in access control which users are authorized to post requests for "TestAgency" as this agency concept is not a product concept.

Regarding tampering with traffic: This only works after the end user carelessly clicked away the browser warning that said: "Your traffic is insecure. Attackers may read or modify...". This is because burp suite will not have a trusted certificate for the target hostname. This behavior is the same for all web applications. If you cannot trust your HTTPS infrastructure, your traffic is not safe.

Hi Team,

I have many security defects reported from my side also regarding Pentest activities applied by Egypt CBE Bank (InovaSys Company)

We opened also multiple tickets and with we came to conclusion that product is working as designed and we should open a REF (Request For Enhancement).

Also I have another idea,

@Mohamed Sobhy

I think to avoid intercepting your API request, you should apply custom encryption over your data from client side and token to your service ( eg. JWT Token )

and in service flow side you should decrepit this logic to get your coach data (however this could produce performance bottleneck) based on how many services used and you should refactor the designed human services.

Also I am interested with solution that @Nitin Upasani applied I have sent an email to get more details.

@Mohammed Shaker

Re: I think to avoid intercepting your API request, you should apply custom encryption over your data from client side and token to your service ( eg. JWT Token )

How would you transmit the encryption key from server to the browser? Burp suite was established as a man-in-the-middle. That is, it can see and modify all traffic. It will see the key and can use it to encrypt/sign its modified request.

Hi @Jens Engelke,

I didn't mention using certificate keys, 

below is just an example of how to implement it using custom encryption logic.

@Mohammed Shaker Your code is creating a signed JWT. The signature uses secureHashKey.key. That's a key that browser and server must have agreed on in order for the server to verify the signature.

If you cannot trust communication between server and browser, then the two cannot agree on a key either.

As the attacker is assumed to be capable of intercepting traffic, he can see the key and sign his own messages in JWT format.

Being able to read and modify traffic, burp suite could even inject additional JavaScript into the browser to modify the message before signing.

Hi Jens Engelke,

You can send additional input called "_token" which is your object data encrypted by some logic the shared from my side in previous comment is just an example and in your service flow (backend) you can encrypt your object again  and compare recieved token (input) and generated token in service if same then proceed with service flow logic if not then you can reach service end or throw excception with needed message.

Hi @Mohammed Shaker

the assumption is: there is a man-in-the-middle, who can read and modify all network traffic between browser and server.

In this position, this man-in-the-middle

• can see any encryption key being exchanged between browser and server
• can see all logic (JavaScript code), which the server sends to the browser in order to hash or encrypt input data into _token
• remove the encryption logic from the JavaScript code
• modify the key seen by the client
• apply the key provided by the server to encrypt modified user input

If this connection is not considered safe for your data, how would be safe to transmit key material or client-side application code?