Questions
ayuda
option
My Daypo

ERASED TEST, YOU MAY BE INTERESTED ONSecure Coding and Testing

COMMENTS STATISTICS RECORDS
TAKE THE TEST
Title of test:
Secure Coding and Testing

Description:
Secure Coding and Testing

Author:
BA
(Other tests from this author)

Creation Date:
03/09/2019

Category:
Others

Number of questions: 19
Share the Test:
Facebook
Twitter
Whatsapp
Share the Test:
Facebook
Twitter
Whatsapp
Last comments
No comments about this test.
Content:
Mishandled errors can leave big holes - best practice is always avoid default messages - always write your own .
Application should verify type and characteristics of input - use fuzzers to test .
Use a single CALL command to invoke very complex queries that cannot be changed - this is a way to avoid security concerns with hosing up the queries .
Confirms that the executable code on the desktop has not been changed .
Development platforms should use encryption so bad guys can't see the source code, and data should always be encrypted .
Taking readable code and / or data and making it look like something it's not so that it's hard to read or use and figure out what's going on (Hello World example) .
Reusing code will spread existing security problems and unneeded code (which might do calculations that aren't used anywhere) is just an opportunity for bad guys .
All checks are occurring on the server - protects against malicious users .
User side validation that can filter out bad users .
Manipulating memory is way to gain access - always validate memory - to avoid things like buffer overflows .
These are used to expand the capability of the code without writing it yourself - obvious risks - best to test test  test the security .
How might sensitive data be stored and relayed across the network, how will it be displayed, etc. .
Tool to go through code to test for security problems - shouldn't be relied on as solo way to test .
Sending random input to an application for analysis - looking for behavior out of the ordinary - crashes, robustness, etc .
Increase the load of an application to see what happens - looking for unintended information .
Separate from the one used in development - it should look a lot like production .
Validation process right before going to PRD - is everything according to specs, does it meet requirements, is this the correct product? .
An executable code that comes from the source code (but isn't the source code) .
Source code is viewable - doesn't have a compiler so don't see any errors until it's ran .
Report abuse Consent Terms of use