arXiv subjects

Mohammad Ghafari

Publications and source records attributed to Mohammad Ghafari.

At least 37 records · Page 2Linked to original sources

arXiv2024

Mining REST APIs for Potential Mass Assignment Vulnerabilities

REST APIs have a pivotal role in accessing protected resources. Despite the availability of security testing tools, mass assignment vulnerabilities are common in REST APIs, leading to unauthorized manipulation of sensitive data. We propose a lightweight approach to mine the REST API specifications and identify operations and attributes that are prone to mass assignment. We conducted a preliminary study on 100 APIs and found 25 prone to this vulnerability. We confirmed nine real vulnerable operations in six APIs.

cs.CR↗

arXiv2024

LLM Security Guard for Code

Many developers rely on Large Language Models (LLMs) to facilitate software development. Nevertheless, these models have exhibited limited capabilities in the security domain. We introduce LLMSecGuard, a framework to offer enhanced code security through the synergy between static code analyzers and LLMs. LLMSecGuard is open source and aims to equip developers with code solutions that are more secure than the code initially generated by LLMs. This framework also has a benchmarking feature, aimed at providing insights into the evolving security attributes of these models.

cs.SE↗

arXiv2023

Insecure by Design in the Backbone of Critical Infrastructure

We inspected 45 actively deployed Operational Technology (OT) product families from ten major vendors and found that every system suffers from at least one trivial vulnerability. We reported a total of 53 weaknesses, stemming from insecure by design practices or basic security design failures. They enable attackers to take a device offline, manipulate its operational parameters, and execute arbitrary code without any constraint. We discuss why vulnerable products are often security certified and appear to be more secure than they actually are, and we explain complicating factors of OT risk management.

cs.CR↗

arXiv2023

Wasmizer: Curating WebAssembly-driven Projects on GitHub

WebAssembly has attracted great attention as a portable compilation target for programming languages. To facilitate in-depth studies about this technology, we have deployed Wasmizer, a tool that regularly mines GitHub projects and makes an up-to-date dataset of WebAssembly sources and their binaries publicly available. Presently, we have collected 2 540 C and C++ projects that are highly-related to WebAssembly, and built a dataset of 8 915 binaries that are linked to their source projects. To demonstrate an application of this dataset, we have investigated the presence of eight WebAssembly compilation smells in the wild.

cs.SE↗

arXiv2023

Naturalistic Static Program Analysis

Static program analysis development is a non-trivial and time-consuming task. We present a framework through which developers can define static program analyses in natural language. We show the application of this framework to identify cryptography misuses in Java programs, and we discuss how it facilitates static program analysis development for developers.

cs.PL↗

arXiv2022

Developers Struggle with Authentication in Blazor WebAssembly

WebAssembly is a growing technology to build cross-platform applications. We aim to understand the security issues that developers encounter when adopting WebAssembly. We mined WebAssembly questions on Stack Overflow and identified 359 security-related posts. We classified these posts into 8 themes, reflecting developer intentions, and 19 topics, representing developer issues in this domain. We found that the most prevalent themes are related to bug fix support, requests for how to implement particular features, clarification questions, and setup or configuration issues. We noted that the topmost issues attribute to authentication in Blazor WebAssembly. We discuss six of them and provide our suggestions to clear these issues in practice.

cs.CR↗

arXiv2022

Mining unit test cases to synthesize API usage examples

Software developers study and reuse existing source code to understand how to properly use application programming interfaces (APIs). However, manually finding sufficient and adequate code examples for a given API is a difficult and a time-consuming activity. Existing approaches to find or generate examples assume availability of a reasonable set of client code that uses the API. This assumption does not hold for newly released API libraries, non-widely used APIs, nor private ones. In this work we reuse the important information that is naturally present in test code to circumvent the lack of usage examples for an API when other sources of client code are not available. We propose an approach for automatically identifying the most representative API uses within each unit test case. We then develop an approach to synthesize API usage examples by extracting relevant statements representing the usage of such APIs. We compare the output of a prototype implementation of our approach to both human-written examples and to a state-of-the-art approach. The obtained results are encouraging; the examples automatically generated with our approach are superior to the state-of-the-art approach and highly similar to the manually constructed examples.

cs.SE↗

arXiv2022

FuzzingDriver: the Missing Dictionary to Increase Code Coverage in Fuzzers

We propose a tool, called FuzzingDriver, to generate dictionary tokens for coverage-based greybox fuzzers (CGF) from the codebase of any target program. FuzzingDriver does not add any overhead to the fuzzing job as it is run beforehand. We compared FuzzingDriver to Google dictionaries by fuzzing six open-source targets, and we found that FuzzingDriver consistently achieves higher code coverage in all tests. We also executed eight benchmarks on FuzzBench to demonstrate how utilizing FuzzingDriver's dictionaries can outperform six widely-used CGF fuzzers. In future work, investigating the impact of FuzzingDriver's dictionaries on improving bug coverage might prove important. Video demonstration: https://www.youtube.com/watch?v=Y8j_KvfRrI8

cs.CR↗

arXiv2021

Security Risks of Porting C Programs to WebAssembly

WebAssembly is a compilation target for cross-platform applications that is increasingly being used. In this paper, we investigate whether one can transparently cross-compile C programs to WebAssembly, and if not, what impact porting can have on their security. We compile 17,802 programs that exhibit common vulnerabilities to 64-bit x86 and to WebAssembly binaries, and we observe that the execution of 4,911 binaries produces different results across these platforms. Through manual inspection, we identify three classes of root causes for such differences: the use of a different standard library implementation, the lack of security measures in WebAssembly, and the different semantics of the execution environments. We describe our observations and discuss the ones that are critical from a security point of view and need most attention from developers. We conclude that compiling an existing C program to WebAssembly for cross-platform distribution may require source code adaptations; otherwise, the security of the WebAssembly application may be at risk.

cs.CR↗

arXiv2021

How Do Developers Deal with Security Issue Reports on GitHub?

Security issue reports are the primary means of informing development teams of security risks in projects, but little is known about current practices. We aim to understand the characteristics of these reports in open-source projects and uncover opportunities to improve developer practices. We analysed 3,493 security issue reports in 182 different projects on GitHub and manually studied 333 reports, and their discussions and pull requests. We found that, the number of security issue reports has increased over time, they are resolved faster, and they are reported in earlier development stages compared to past years. Nevertheless, a tiny group of developers are involved frequently, security issues progress slowly, and a great number of them has been pending for a long time. We realized that only a small subset of security issue reports include reproducibility data, a potential fix is rarely suggested, and there is no hint regarding how a reporter spotted an issue. We noted that the resolution time of an issue is significantly shorter when the first reaction to a security report is fast and when a reference to a known vulnerability exists.

cs.CR↗

arXiv2021

Cryptography Vulnerabilities on HackerOne

Previous studies have shown that cryptography is hard for developers to use and misusing cryptography leads to severe security vulnerabilities. We studied relevant vulnerability reports on the HackerOne bug bounty platform to understand what types of cryptography vulnerabilities exist in the wild. We extracted eight themes of vulnerabilities from the vulnerability reports and discussed their real-world implications and mitigation strategies. We hope that our findings alert developers, familiarize them with the dire consequences of cryptography misuses, and support them in avoiding such mistakes.

cs.CR↗

arXiv2021

Phish What You Wish

IT professionals have no simple tool to create phishing websites and raise the awareness of users. We developed a prototype that can dynamically mimic websites by using enriched screenshots, which requires no additional programming experience and is simple to set up. The generated websites are functional and remain up-to-date. We found that 98% of the hyperlinks in mimicked websites are functional with our tool, compared to 43% with the best competitor, and only two participants suspected phishing attempts at the time they were performing tasks with our prototype. This work intends to raise awareness for phishing attempts especially with local websites by providing an easy to use prototype to set up such phishing sites.

cs.CR↗

arXiv2021

Security Header Fields in HTTP Clients

HTTP headers are commonly used to establish web communications, and some of them are relevant for security. However, we have only little information about the usage and support of security-relevant headers in mobile applications. We explored the adoption of such headers in mobile app communication by querying 9,714 distinct URLs that were used in 3,376 apps and collected each server's response information. We discovered that support for secure HTTP header fields is absent in all major HTTP clients, and it is barely provided with any server response. Based on these results, we discuss opportunities for improvement particularly to reduce the likelihood of data leaks and arbitrary code execution. We advocate more comprehensive use of existing HTTP headers and timely development of relevant web browser security features in HTTP client libraries.

cs.CR↗

arXiv2021

Dazed and Confused: What's Wrong with Crypto Libraries?

Recent studies have shown that developers have difficulties in using cryptographic APIs, which often led to security flaws. We are interested to tackle this matter by looking into what types of problems exist in various crypto libraries. We manually studied 500 posts on Stack Overflow associated with 20 popular crypto libraries. We realized there are 10 themes in the discussions. Interestingly, there were only two questions related to attacks against cryptography. There were 63 discussions in which developers had interoperability issues when working with more than a crypto library. The majority of posts (i.e. 112) were about encryption/decryption problems and 111 were about installation/compilation issues of crypto libraries. Overall, we realize that the crypto libraries are frequently involved in more than five themes of discussions. We believe the current initial findings can help team leaders and experienced developers to correctly guide the team members in the domain of cryptography. Moreover, future research should investigate the similarity of problems at the API level among popular crypto libraries.

cs.CR↗

arXiv2021

The Security Risk of Lacking Compiler Protection in WebAssembly

WebAssembly is increasingly used as the compilation target for cross-platform applications. In this paper, we investigate whether one can rely on the security measures enforced by existing C compilers when compiling C programs to WebAssembly. We compiled 4,469 C programs with known buffer overflow vulnerabilities to x86 code and to WebAssembly, and observed the outcome of the execution of the generated code to differ for 1,088 programs. Through manual inspection, we identified that the root cause for these is the lack of security measures such as stack canaries in the generated WebAssembly: while x86 code crashes upon a stack-based buffer overflow, the corresponding WebAssembly continues to be executed. We conclude that compiling an existing C program to WebAssembly without additional precautions may hamper its security, and we encourage more research in this direction.

cs.CR↗

arXiv2021

Worrisome Patterns in Developers: A Survey in Cryptography

We surveyed 97 developers who had used cryptography in open-source projects, in the hope of identifying developer security and cryptography practices. We asked them about individual and company-level practices, and divided respondents into three groups (i.e., high, medium, and low) based on their level of knowledge. We found differences between the high-profile developers and the other two groups. For instance, high-profile developers have more years of experience in programming, have attended more security and cryptography courses, have more background in security, are highly concerned about security, and tend to use security tools more than the other two groups. Nevertheless, we observed worrisome patterns among all participants such as the high usage of unreliable sources like Stack Overflow, and the low rate of security tool usage.

cs.CR↗

arXiv2021

Crypto Experts Advise What They Adopt

Previous studies have shown that developers regularly seek advice on online forums to resolve their cryptography issues. We investigated whether users who are active in cryptography discussions also use cryptography in practice. We collected the top 1% of responders who have participated in crypto discussions on Stack Overflow, and we manually analyzed their crypto contributions to open source projects on GitHub. We could identify 319 GitHub profiles that belonged to such crypto responders and found that 189 of them used cryptography in their projects. Further investigation revealed that the majority of analyzed users (i.e., 85%) use the same programming languages for crypto activity on Stack Overflow and crypto contributions on GitHub. Moreover, 90% of the analyzed users employed the same concept of cryptography in their projects as they advised about on Stack Overflow.

cs.CR↗

arXiv2021

What Do Developers Discuss about Code Comments?

Code comments are important for program comprehension, development, and maintenance tasks. Given the varying standards for code comments, and their unstructured or semi-structured nature, developers get easily confused (especially novice developers) about which convention(s) to follow, or what tools to use while writing code documentation. Thus, they post related questions on external online sources to seek better commenting practices. In this paper, we analyze code comment discussions on online sources such as Stack Overflow (SO) and Quora to shed some light on the questions developers ask about commenting practices. We apply Latent Dirichlet Allocation (LDA) to identify emerging topics concerning code comments. Then we manually analyze a statistically significant sample set of posts to derive a taxonomy that provides an overview of the developer questions about commenting practices. Our results highlight that on SO nearly 40% of the questions mention how to write or process comments in documentation tools and environments, and nearly 20% of the questions are about potential limitations and possibilities of documentation tools to add automatically and consistently more information in comments. On the other hand, on Quora, developer questions focus more on background information (35% of the questions) or asking opinions (16% of the questions) about code comments. We found that (i) not all aspects of comments are covered in coding style guidelines, e.g., how to add a specific type of information, (ii) developers need support in learning the syntax and format conventions to add various types of information in comments, and (iii) developers are interested in various automated strategies for comments such as detection of bad comments, or verify comment style automatically, but lack tool support to do that.

cs.SE↗