reyesreg / spacewalker Goto Github PK

• Name: SQL Injection
• ID: 0a3b9cad337a0100a047fa6161b57439
• Affected Hosts: ['http://testphp.vulnweb.com/secured/newuser.php']
• Description: SQL injection may be possible.
• First seen: 2018-06-08 08:13:00
• Recommendation: Do not trust client side input, even if there is client side validation in place.
  In general, type check all data on the server side.
  If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'
  If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.
  If database Stored Procedures can be used, use them.
  Do not concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!
  Do not create dynamic SQL queries using simple string concatenation.
  Escape all data received from the client.
  Apply a 'whitelist' of allowed characters, or a 'blacklist' of disallowed characters in user input.
  Apply the principle of least privilege by using the least privileged database user possible.
  In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.
  Grant the minimum database access that is necessary for the application.
• Source Link: https://staging.horangi.com/storyfier/detect/f67ba203-0e81-4164-a8d1-633d7e74c1a7/0a3b9cad337a0100a047fa6161b57439

Risk: critical

Description

It was discovered that one or more code repository(ies) contains API keys. API keys in code are a major vulnerability in an otherwise secure system as these give out authorized access into your system.

Implication

Publicly exposing API keys can result in unintended use, which could lead to unexpected charges if the API is paid on a per-use basis.

Once an attacker gets a credential, they can take over an account, lock legitimate users out, and do various attacks to your infrastructure. This can lead to a domino effect where access to one grants access to other accounts.

Recommendation

It is recommended to remove secrets from code and regenerate new ones. To pipe the credentials through the application, and replace any mention of the secret(s) with one of the following:

1. An environment variable placeholder
2. A function parsing an encrypted configuration file where credentials are stored.

Code

Link : https://github.com/reyesreg/mountain-app/blob/504e01ce3323c94497541de8ea40ceecf14acf52/src/Helpers/FirebaseDB.js#L4

Author: [email protected]

Horangi detected this issue on 2019-08-08 01:52:33.734977

• Name: Buffer Underflow
• ID: bc6839967ebf463d34d1d81af246362b
• Affected Hosts: 129.9.9.1
• Description: Dummy Description
• First seen: 2014-02-91
• Recommendation: rm -rf
• Source Link: /storyfier/detect/c243c7bc-4de2-4156-a135-8b5dbd6df4b2/bc6839967ebf463d34d1d81af246362b

• Name: Cross Site Scripting (Reflected)
• ID: cef41d30202a48c4f70d9c1430e5650c
• Affected Hosts: ['http://testphp.vulnweb.com/listproducts.php?cat=%3C%2Fdiv%3E%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E%3Cdiv%3E']
• Description: Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's browser instance. A browser instance can be a standard web browser client, or a browser object embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.
  When an attacker gets a user's browser to execute his/her code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the web site they are visiting. Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site. Applications utilizing browser object instances which load content from the file system may execute code under the local machine zone allowing for system compromise.

There are three types of Cross-site Scripting attacks: non-persistent, persistent and DOM-based.
Non-persistent attacks and DOM-based attacks require a user to either visit a specially crafted link laced with malicious code, or visit a malicious web page containing a web form, which when posted to the vulnerable site, will mount the attack. Using a malicious form will oftentimes take place when the vulnerable resource only accepts HTTP POST requests. In such a case, the form can be submitted automatically, without the victim's knowledge (e.g. by using JavaScript). Upon clicking on the malicious link or submitting the malicious form, the XSS payload will get echoed back and will get interpreted by the user's browser and execute. Another technique to send almost arbitrary requests (GET and POST) is by using an embedded client, such as Adobe Flash.
Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to interact with any additional site/link (e.g. an attacker site or a malicious link sent via email), just simply view the web page containing the code.

• First seen: 2018-06-08 08:13:00
• Recommendation: Phase: Architecture and Design
  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.

Phases: Implementation; Architecture and Design
Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.
Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are needed.

Phase: Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.

Phase: Implementation
For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8. When an encoding is not specified, the web browser may choose a different encoding by guessing which encoding is actually being used by the web page. This can cause the web browser to treat certain sequences as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to encoding/escaping.

To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.

• Source Link: https://staging.horangi.com/storyfier/detect/f67ba203-0e81-4164-a8d1-633d7e74c1a7/cef41d30202a48c4f70d9c1430e5650c

• Name: Cross Site Scripting (Reflected)
• ID: 8a029c8d30d5eb6ecde6077d9b8f49f8
• Affected Hosts: ['http://testphp.vulnweb.com/secured/newuser.php']
• Description: Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's browser instance. A browser instance can be a standard web browser client, or a browser object embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.
  When an attacker gets a user's browser to execute his/her code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the web site they are visiting. Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site. Applications utilizing browser object instances which load content from the file system may execute code under the local machine zone allowing for system compromise.

There are three types of Cross-site Scripting attacks: non-persistent, persistent and DOM-based.
Non-persistent attacks and DOM-based attacks require a user to either visit a specially crafted link laced with malicious code, or visit a malicious web page containing a web form, which when posted to the vulnerable site, will mount the attack. Using a malicious form will oftentimes take place when the vulnerable resource only accepts HTTP POST requests. In such a case, the form can be submitted automatically, without the victim's knowledge (e.g. by using JavaScript). Upon clicking on the malicious link or submitting the malicious form, the XSS payload will get echoed back and will get interpreted by the user's browser and execute. Another technique to send almost arbitrary requests (GET and POST) is by using an embedded client, such as Adobe Flash.
Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to interact with any additional site/link (e.g. an attacker site or a malicious link sent via email), just simply view the web page containing the code.

• First seen: 2018-06-08 08:13:00
• Recommendation: Phase: Architecture and Design
  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.

Phases: Implementation; Architecture and Design
Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.
Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are needed.

Phase: Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.

Phase: Implementation
For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8. When an encoding is not specified, the web browser may choose a different encoding by guessing which encoding is actually being used by the web page. This can cause the web browser to treat certain sequences as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to encoding/escaping.

To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.

• Source Link: https://staging.horangi.com/storyfier/detect/f67ba203-0e81-4164-a8d1-633d7e74c1a7/8a029c8d30d5eb6ecde6077d9b8f49f8

Risk: critical

Description

Because it is easy to extract strings from a compiled application, credentials
should never be hard-coded. Do so, and they're almost guaranteed to end up in
the hands of an attacker. This is particularly true for applications that are
distributed.

Credentials should be stored outside of the code in a strongly-protected
encrypted configuration file or database.

Noncompliant Code Example

$uname = "steve";
$password = "blue";
connect($uname, $password);

Compliant Solution

$uname = getEncryptedUser();
$password = getEncryptedPass();
connect($uname, $password);

See

• MITRE, CWE-798 - Use of Hard-coded Credentials
• MITRE, CWE-259 - Use of Hard-coded Password
• SANS Top 25 - Porous Defenses
• CERT, MSC03-J. - Never hard code sensitive information
• OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management
• Derived from FindSecBugs rule Hard Coded Password

Recommendation

Remove this hard-coded password.

Code

Link : https://bitbucket.org/jeffrey1/sonar-lang-test2/src/f5389f8733871d071fa933b76bdd0b4ad9939962/hello-php.php?fileviewer=file-view-default#hello-php.php-7

Author: [email protected]

Horangi detected this issue on 2019-04-14 07:54:45.898372

Risk: medium

Description

An issue is created on a file as soon as there is at least one block of
duplicated code on this file

Recommendation

13 duplicated blocks of code must be removed.

Code

Link : https://github.com/reyesreg/student-portal-project/blob/9830827e9b71840c2f5ee1c4531be99af2ed16d2/php/inv_controllers/admin_func/approve_post.php

Author: [email protected]

Link : https://github.com/reyesreg/student-portal-project/blob/9830827e9b71840c2f5ee1c4531be99af2ed16d2/php/inv_controllers/admin_func/archive_post.php

Author: [email protected]

Horangi detected this issue on 2019-04-14 09:19:09.864850

Risk: Medium

Code

https://github.com/reyesreg/spacewalker/blob/f366416d694d454fec6b3d1f5f9f597493532a29/components/astronaut.js#L72

Description

A dead store happens when a local variable is assigned a value that is not read by any subsequent instruction or when an object property is assigned a value that is not subsequently used. Calculating or retrieving a value only to then overwrite it or throw it away, could indicate a serious error in the code. Even if it's not an error, it is at best a waste of resources. Therefore all calculated values should be used.

Noncompliant Code Example

function pow(a, b) {
  if(b == 0) {
    return 0;
  }
  var x = a;
  for(var i = 1; i < b; i++) {
    x = x * a;  //Dead store because the last return statement should return x instead of returning a
  }
  return a;
}

Compliant Solution

function pow(a, b) {
  if(b == 0) {
    return 0;
  }
  var x = a;
  for(var i = 1; i < b; i++) {
    x = x * a;
  }
  return x;
}

Exceptions

This rule ignores initializations to -1, 0, 1, null, true, false, "", [] and {}.

See

• MITRE, CWE-563 - Assignment to Variable without Use ('Unused Variable')
• CERT, MSC13-C. - Detect and remove unused values
• CERT, MSC13-CPP. - Detect and remove unused values
• CERT, MSC56-J. - Detect and remove superfluous code and values
• CERT, MSC12-CPP. - Detect and remove code that has no effect

Recommendation

Remove this useless assignment to local variable "fireSlideStyle"

Horangi detected this issue on 2018-10-05 07:26:40

Risk: informational

Description

This PHP code contains TODO tags. TODO tags are commonly used to mark places where some more code is required, but which the developer wants to implement later.

Noncompliant Code Example

function doSomething() {
  // TODO
}

References

• MITRE, CWE-546 - Suspicious Comment

Implication

Sometimes the developer will not have the time or will simply forget to get back to that tag and the issue is eventually not fixed.

Recommendation

It is recommended to complete the task associated with this TODO comment.

Code

Link : https://github.com/reyesreg/student-portal-project/blob/9830827e9b71840c2f5ee1c4531be99af2ed16d2/php/index_control.php#L88

Author: [email protected]

Horangi detected this issue on 2019-05-22 04:27:11.643265

• Name: Cross Site Scripting (Reflected)
• ID: 8a029c8d30d5eb6ecde6077d9b8f49f8
• Affected Hosts: ['http://testphp.vulnweb.com/secured/newuser.php']
• Description: Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's browser instance. A browser instance can be a standard web browser client, or a browser object embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.
  When an attacker gets a user's browser to execute his/her code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the web site they are visiting. Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site. Applications utilizing browser object instances which load content from the file system may execute code under the local machine zone allowing for system compromise.

There are three types of Cross-site Scripting attacks: non-persistent, persistent and DOM-based.
Non-persistent attacks and DOM-based attacks require a user to either visit a specially crafted link laced with malicious code, or visit a malicious web page containing a web form, which when posted to the vulnerable site, will mount the attack. Using a malicious form will oftentimes take place when the vulnerable resource only accepts HTTP POST requests. In such a case, the form can be submitted automatically, without the victim's knowledge (e.g. by using JavaScript). Upon clicking on the malicious link or submitting the malicious form, the XSS payload will get echoed back and will get interpreted by the user's browser and execute. Another technique to send almost arbitrary requests (GET and POST) is by using an embedded client, such as Adobe Flash.
Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to interact with any additional site/link (e.g. an attacker site or a malicious link sent via email), just simply view the web page containing the code.

• First seen: 2018-06-08 08:13:00
• Recommendation: Phase: Architecture and Design
  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.

Phases: Implementation; Architecture and Design
Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.
Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are needed.

Phase: Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.

Phase: Implementation
For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8. When an encoding is not specified, the web browser may choose a different encoding by guessing which encoding is actually being used by the web page. This can cause the web browser to treat certain sequences as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to encoding/escaping.

To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.

• Source Link: https://staging.horangi.com/storyfier/detect/f67ba203-0e81-4164-a8d1-633d7e74c1a7/8a029c8d30d5eb6ecde6077d9b8f49f8

Risk: critical

Description

When the execution is not explicitly terminated at the end of a switch case,
it continues to execute the statements of the following case. While this is
sometimes intentional, it often is a mistake which leads to unexpected
behavior.

Noncompliant Code Example

switch (myVariable) {
  case 1:
    foo();
    break;
  case 2:  // Both 'doSomething()' and 'doSomethingElse()' will be executed. Is it on purpose ?
    doSomething();
  default:
    doSomethingElse();
    break;
}

Compliant Solution

switch (myVariable) {
  case 1:
    foo();
    break;
  case 2:
    doSomething();
    break;
  default:
    doSomethingElse();
    break;
}

Exceptions

This rule is relaxed in the following cases:

switch (myVariable) {
  case 0:                                // Empty case used to specify the same behavior for a group of cases.
  case 1:
    doSomething();
    break;
  case 2:                                // Use of return statement
    return;
  case 3:                               // Ends with comment when fall-through is intentional
    console.log("this case falls through")
    // fall through
  case 4:                                // Use of throw statement
    throw new IllegalStateException();
  case 5:                                // Use of continue statement
    continue;
  default:                               // For the last case, use of break statement is optional
    doSomethingElse();
}

See

• MISRA C:2004, 15.0 - The MISRA C switch syntax shall be used.
• MISRA C:2004, 15.2 - An unconditional break statement shall terminate every non-empty switch clause
• MISRA C++:2008, 6-4-3 - A switch statement shall be a well-formed switch statement.
• MISRA C++:2008, 6-4-5 - An unconditional throw or break statement shall terminate every non-empty switch-clause
• MISRA C:2012, 16.1 - All switch statements shall be well-formed
• MISRA C:2012, 16.3 - An unconditional break statement shall terminate every switch-clause
• MITRE, CWE-484 - Omitted Break Statement in Switch
• CERT, MSC17-C. - Finish every set of statements associated with a case label with a break statement
• CERT, MSC18-CPP. - Finish every set of statements associated with a case label with a break statement
• CERT, MSC52-J. - Finish every set of statements associated with a case label with a break statement

Recommendation

End this switch case with an unconditional break, continue, return or throw statement.

Code

https://github.com/reyesreg/react-todo/blob/89aa7360990ded17a76364355a35df86d7eee9dc/dist/bundle.js#L22182

Horangi detected this issue on 2019-04-12 08:18:17.154021

• Name: Buffer Underflow
• ID: bc6839967ebf463d34d1d81af246362b
• Affected Hosts: 129.9.9.1
• Description: Dummy Description
• First seen: 2014-02-91
• Recommendation: rm -rf
• Source Link: /storyfier/detect/c243c7bc-4de2-4156-a135-8b5dbd6df4b2/bc6839967ebf463d34d1d81af246362b

• Name: Cross Site Scripting (Reflected)
• ID: 8a029c8d30d5eb6ecde6077d9b8f49f8
• Affected Hosts: ['http://testphp.vulnweb.com/secured/newuser.php']
• Description: Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's browser instance. A browser instance can be a standard web browser client, or a browser object embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.
  When an attacker gets a user's browser to execute his/her code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the web site they are visiting. Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site. Applications utilizing browser object instances which load content from the file system may execute code under the local machine zone allowing for system compromise.

There are three types of Cross-site Scripting attacks: non-persistent, persistent and DOM-based.
Non-persistent attacks and DOM-based attacks require a user to either visit a specially crafted link laced with malicious code, or visit a malicious web page containing a web form, which when posted to the vulnerable site, will mount the attack. Using a malicious form will oftentimes take place when the vulnerable resource only accepts HTTP POST requests. In such a case, the form can be submitted automatically, without the victim's knowledge (e.g. by using JavaScript). Upon clicking on the malicious link or submitting the malicious form, the XSS payload will get echoed back and will get interpreted by the user's browser and execute. Another technique to send almost arbitrary requests (GET and POST) is by using an embedded client, such as Adobe Flash.
Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to interact with any additional site/link (e.g. an attacker site or a malicious link sent via email), just simply view the web page containing the code.

• First seen: 2018-06-08 08:13:00
• Recommendation: Phase: Architecture and Design
  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.

Phases: Implementation; Architecture and Design
Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.
Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are needed.

Phase: Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.

Phase: Implementation
For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8. When an encoding is not specified, the web browser may choose a different encoding by guessing which encoding is actually being used by the web page. This can cause the web browser to treat certain sequences as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to encoding/escaping.

To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.

• Source Link: https://staging.horangi.com/storyfier/detect/f67ba203-0e81-4164-a8d1-633d7e74c1a7/8a029c8d30d5eb6ecde6077d9b8f49f8

• Name: Cross Site Scripting (Reflected)
• ID: 8a029c8d30d5eb6ecde6077d9b8f49f8
• Affected Hosts: ['http://testphp.vulnweb.com/secured/newuser.php']
• Description: Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's browser instance. A browser instance can be a standard web browser client, or a browser object embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.
  When an attacker gets a user's browser to execute his/her code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the web site they are visiting. Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site. Applications utilizing browser object instances which load content from the file system may execute code under the local machine zone allowing for system compromise.

There are three types of Cross-site Scripting attacks: non-persistent, persistent and DOM-based.
Non-persistent attacks and DOM-based attacks require a user to either visit a specially crafted link laced with malicious code, or visit a malicious web page containing a web form, which when posted to the vulnerable site, will mount the attack. Using a malicious form will oftentimes take place when the vulnerable resource only accepts HTTP POST requests. In such a case, the form can be submitted automatically, without the victim's knowledge (e.g. by using JavaScript). Upon clicking on the malicious link or submitting the malicious form, the XSS payload will get echoed back and will get interpreted by the user's browser and execute. Another technique to send almost arbitrary requests (GET and POST) is by using an embedded client, such as Adobe Flash.
Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to interact with any additional site/link (e.g. an attacker site or a malicious link sent via email), just simply view the web page containing the code.

• First seen: 2018-06-08 08:13:00
• Recommendation: Phase: Architecture and Design
  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.

Phases: Implementation; Architecture and Design
Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.
Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are needed.

Phase: Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.

Phase: Implementation
For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8. When an encoding is not specified, the web browser may choose a different encoding by guessing which encoding is actually being used by the web page. This can cause the web browser to treat certain sequences as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to encoding/escaping.

To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.

• Source Link: https://staging.horangi.com/storyfier/detect/f67ba203-0e81-4164-a8d1-633d7e74c1a7/8a029c8d30d5eb6ecde6077d9b8f49f8

Risk: medium

Description

When a variable is assigned an undefined or null value, it has no
properties. Trying to access properties of such a variable anyway results in a
TypeError, causing abrupt termination of the script if the error is not
caught in a catch block. But instead of catch-ing this condition, it is
best to avoid it altogether.

Noncompliant Code Example

if (x === undefined) {
  console.log(x.length); // Noncompliant; TypeError will be thrown
}

See

• MITRE, CWE-476 - NULL Pointer Dereference
• CERT, EXP34-C. - Do not dereference null pointers
• CERT, EXP01-J. - Do not use a null in a case where an object is required

Recommendation

TypeError can be thrown as "instance" might be null or undefined here.

Code

https://github.com/reyesreg/react-todo/blob/89aa7360990ded17a76364355a35df86d7eee9dc/dist/bundle.js#L21643
https://github.com/reyesreg/react-todo/blob/89aa7360990ded17a76364355a35df86d7eee9dc/dist/bundle.js#L25362
https://github.com/reyesreg/react-todo/blob/89aa7360990ded17a76364355a35df86d7eee9dc/dist/bundle.js#L14502
https://github.com/reyesreg/react-todo/blob/89aa7360990ded17a76364355a35df86d7eee9dc/dist/bundle.js#L37668
https://github.com/reyesreg/react-todo/blob/89aa7360990ded17a76364355a35df86d7eee9dc/dist/bundle.js#L37949
https://github.com/reyesreg/react-todo/blob/89aa7360990ded17a76364355a35df86d7eee9dc/dist/bundle.js#L40356
https://github.com/reyesreg/react-todo/blob/89aa7360990ded17a76364355a35df86d7eee9dc/dist/bundle.js#L40424
https://github.com/reyesreg/react-todo/blob/89aa7360990ded17a76364355a35df86d7eee9dc/dist/bundle.js#L43643

Horangi detected this issue on 2019-04-12 10:15:15.394506

• Name: X-Frame-Options Header Not Set
• ID: 0e6f6027c2eabd6bfbfcd99875272467
• Affected Hosts: ['http://yachts.coinonsale.com:8080']
• Description: X-Frame-Options header is not included in the HTTP response to protect against 'ClickJacking' attacks.
• First seen: 2018-06-08 08:13:00
• Recommendation: Most modern Web browsers support the X-Frame-Options HTTP header. Ensure it's set on all web pages returned by your site (if you expect the page to be framed only by pages on your server (e.g. it's part of a FRAMESET) then you'll want to use SAMEORIGIN, otherwise if you never expect the page to be framed, you should use DENY. ALLOW-FROM allows specific websites to frame the web page in supported web browsers).
• Source Link: https://staging.horangi.com/storyfier/detect/f34a65ab-6957-4b0c-a761-ab58391142ba/0e6f6027c2eabd6bfbfcd99875272467

• Name: Buffer Underflow
• ID: testvulnoncollab
• Affected Hosts: 129.9.9.1
• Description: Dummy Description
• First seen: 2014-02-91
• Recommendation: rm -rf
• Source Link: /storyfier/detect/c243c7bc-4de2-4156-a135-8b5dbd6df4b2/testvulnoncollab

• Name: X-Frame-Options Header Not Set
• ID: 0e6f6027c2eabd6bfbfcd99875272467
• Affected Hosts: ['http://yachts.coinonsale.com:8080']
• Description: X-Frame-Options header is not included in the HTTP response to protect against 'ClickJacking' attacks.
• First seen: 2018-06-08 08:13:00
• Recommendation: Most modern Web browsers support the X-Frame-Options HTTP header. Ensure it's set on all web pages returned by your site (if you expect the page to be framed only by pages on your server (e.g. it's part of a FRAMESET) then you'll want to use SAMEORIGIN, otherwise if you never expect the page to be framed, you should use DENY. ALLOW-FROM allows specific websites to frame the web page in supported web browsers).
• Source Link: https://staging.horangi.com/storyfier/detect/f34a65ab-6957-4b0c-a761-ab58391142ba/0e6f6027c2eabd6bfbfcd99875272467

Risk: informational

Details

• ID: 2d52bfb2-305b-41f1-bfbb-df9890a26eaf

Description

X-Frame-Options header is not included in the HTTP response to protect against 'ClickJacking' attacks.

Recommendation

Most modern Web browsers support the X-Frame-Options HTTP header. Ensure it's set on all web pages returned by your site (if you expect the page to be framed only by pages on your server (e.g. it's part of a FRAMESET) then you'll want to use SAMEORIGIN, otherwise if you never expect the page to be framed, you should use DENY. ALLOW-FROM allows specific websites to frame the web page in supported web browsers).

Affected Hosts

• Affected Hosts:
  • https://www.example.com
  • http://kolyaak.github.io

Horangi detected this issue on 2019-04-07 05:57:27.140238

Details

• ID: a1f40e323b06d43d7f9fa6d5a2ccdbfc
• Affected Hosts: 129.9.9.1
• First seen: 2014-02-91

Description

Dummy Description

Recommendation

rm -rf