Monday, September 26, 2011

Security Testing - Test for Buffer Overflows


Test for Buffer Overflows

One of the first security bugs exploited in computer history was a buffer overflow. Buffer overflows continue to be one of the most dangerous and most commonly occurring weaknesses. Attempts to exploit this type of vulnerability can result in problems ranging from crashing the application to an attacker inserting and executing malignant code in the application process.
When writing data to buffers, it is imperative that developers not write more to the buffer than it can possibly hold. If the amount of data being written exceeds the buffer space that has been allocated, a buffer overflow occurs. When a buffer overflow occurs, data is written into parts of memory that may be allocated for other purposes. A worst-case scenario is when the buffer overflow contains malicious code that is then executed. Buffer overflows account for a large percentage of security vulnerabilities.

How to write Status Report

Hey folks,

Status report can be Daily status report, Weekly status report or Monthly status report.  It depends how you make it and for which type of model you are preparing it. It differ from Agile to waterfall and prototype model.

It can be include
  • Current Status v. Plan (Ahead/Behind/On Schedule)
  • Progress of tasks planned for previous week
  • Tasks planned for next week including tasks carried from previous week
  • Error Statistics from Error Measurement system
  • Issues/Risks
  • Test case count information, if any.
  • Any observation or blockage  
  • File format name should be proper and consist
  • Give Attachment reference like what you are attached with mail like traceability metrics, test cases, test scenarios, query document etc along with module name.
  • Give build and Environment detail information on which you test the functionality as discussed on call or mail information
  • Give defect validation reference
    • a. Defect# - open/Close/Reopen/Fail
  • Give Query information proper for new ITGs requirement, During testing found any difficulty
  • If multiple module's execution came at a time, then heading ITG name in proper way along with below details.
    • Give Functional Observation
    • Give Regression Observation
  • Give Ad hoc testing scenarios as reference, if any
  • Give summary of execution if any like Block Test cases # along with count and proper detail with reason (Defect#,environment issue etc)
  • Active defect summary for the module
  • Give notes information, like any reminder, holidays, leaves etc.
  • Attach all the required document
  • Check for spell and grammar.